>I am using NTPd and I have guessed that it uses the High Resolution Timer,
>brought to the linux kernel since the 2.6.16 release.
>Does anyone know if it said somewhere in the documentation or any other
>"official" source, a trusty one.

ntpd "just" calls the kernel.

Recent Linux kernels have several modules for timekeeping.
Look in .../Documentation/kernel-parameters.txt


I think the normal one is TSC. (At least on the machines I've
worked with.) The TSC calibration code is buggy. It doesn't
quite get the same answer each time. (If you patch the kernel
to call it several times, you will get several different answers.)

It's very close, but it's off by enough to confuse ntpd. In
particular, it will introuduce a startup transient after each
roboot until ntpd figures out the new drift value. It took my
system several/many hours to do that.

I haven't seen that problem since I added
clocksource=acpi_pm
on the boot time parameters.

--
These are my opinions, not necessarily my employer's. I hate spam.

hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:

>>I am using NTPd and I have guessed that it uses the High Resolution Timer,
>>brought to the linux kernel since the 2.6.16 release.
>>Does anyone know if it said somewhere in the documentation or any other
>>"official" source, a trusty one.

>ntpd "just" calls the kernel.

>Recent Linux kernels have several modules for timekeeping.
>Look in .../Documentation/kernel-parameters.txt


>I think the normal one is TSC. (At least on the machines I've
>worked with.) The TSC calibration code is buggy. It doesn't
>quite get the same answer each time. (If you patch the kernel
>to call it several times, you will get several different answers.)

>It's very close, but it's off by enough to confuse ntpd. In
>particular, it will introuduce a startup transient after each
>roboot until ntpd figures out the new drift value. It took my
>system several/many hours to do that.

>I haven't seen that problem since I added
> clocksource=acpi_pm
>on the boot time parameters.

What version of the kernel do you have? 2.6.17 does not have clocksource
parameter or an acpi_pm option. Is there anywhere where these different
clock parameters are defined?

>>I haven't seen that problem since I added
>> clocksource=acpi_pm
>>on the boot time parameters.
>
>What version of the kernel do you have? 2.6.17 does not have clocksource
>parameter or an acpi_pm option. Is there anywhere where these different
>clock parameters are defined?

I'm using 2.6.23. Documentation/kernel-parameters.txt says:

clocksource= [GENERIC_TIME] Override the default clocksource
Format:
Override the default clocksource and use the clocksource
with the name specified.
Some clocksource names to choose from, depending on
the platform:
[all] jiffies (this is the base, fallback clocksource)
[ACPI] acpi_pm
[ARM] imx_timer1,OSTS,netx_timer,mpu_timer2,
pxa_timer,timer3,32k_counter,timer0_1
[AVR32] avr32
[X86-32] pit,hpet,tsc,vmi-timer;
scx200_hrt on Geode; cyclone on IBM x440
[MIPS] MIPS
[PARISC] cr16
[S390] tod
[SH] SuperH
[SPARC64] tick
[X86-64] hpet,tsc


--
These are my opinions, not necessarily my employer's. I hate spam.

On Tue, Apr 29, 2008 at 2:36 PM, Hal Murray
wrote:

> [X86-32] pit,hpet,tsc,vmi-timer;
....
> [SPARC64] tick
> [X86-64] hpet,tsc


Does the HPET support enable microsecond resolution for hardware clock
reads in Linux (the HPET hardware is supposedly capable of this)?


--
RPM

Ryan Malayter wrote:

>
> Does the HPET support enable microsecond resolution for hardware clock
> reads in Linux (the HPET hardware is supposedly capable of this)?

Even the CTC allows microsecond resolution. Unless you are Windows, you
read tbe balance of the countdown value to interpolate between interrupts.


>
>

>Does the HPET support enable microsecond resolution for hardware clock
>reads in Linux (the HPET hardware is supposedly capable of this)?

I don't know. A quick test with my kernel seemed to ignore
that chunk of the command line. I may have it turned off in
the config file.

--
These are my opinions, not necessarily my employer's. I hate spam.

On Wed, Apr 30, 2008 at 1:27 AM, David Woolley
wrote:
> > Does the HPET support enable microsecond resolution for hardware clock
> > reads in Linux (the HPET hardware is supposedly capable of this)?
>
> Even the CTC allows microsecond resolution. Unless you are Windows, you
> read tbe balance of the countdown value to interpolate between interrupts.

Ahh... I see. So the only real timing benefit of the HPET is the
ability to set timer interrupts with microsecond accuracy? That makes
sense for multimedia, I suppose.

--
RPM

Unruh wrote:

> What version of the kernel do you have? 2.6.17 does not have clocksource
> parameter or an acpi_pm option. Is there anywhere where these different
> clock parameters are defined?

# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc acpi_pm pit jiffies

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc