[ntp:questions] Time reset

Andy Helten andy.helten at dot21rts.com
Fri Apr 4 19:52:06 UTC 2008


Hal wrote:

>> My current problem is that drift settles at 82ppm (what I called <90 in
>> previous email) in one run and then 32ppm in another run (with a reboot
>> between).  This is similar to the problem I had with stepping disabled
>> where drift would go from +500ppm in one run and then swing all the way
>> to -500ppm in another run (usually with a reboot between).  I am not
>> going to spend another minute troubleshooting this problem until we get
>> an updated linux kernel.  I will dig into it more deeply if the new
>> kernel exhibits this same drift instability.
>>     
>
> I think we are talking about two different bugs here.
>
> The different drifts on reboot are due to a quirk in the tsc
> calibration code in the kernal.  Grep your sys log for messages
> like these:
>   Mar 30 21:56:23 shuksan kernel: Detected 2793.091 MHz processor.
>   Mar 30 22:23:28 shuksan kernel: Detected 2793.067 MHz processor.
>   Mar 30 22:42:31 shuksan kernel: Detected 2793.037 MHz processor.
>   Mar 30 23:03:21 shuksan kernel: Detected 2793.085 MHz processor.
>   Mar 31 00:07:37 shuksan kernel: Detected 2793.147 MHz processor.
> Those bottom bits jumping arround correspond to the different
> drift values.
>
> If you only have one system, you can pick one and hack your
> kernel to smash in a constant value at the right place.
>
> Or you can add something like this to your boot line:
>   clocksource=acpi_pm
> That's assuming your hardware has acpi and whatever.
>
> I've been using it for a while.  I haven't noticed any quirks,
> but who knows.
>
>   

YES!  The slight variation in measured CPU speed seems to explain my
continued drift instability (where "continued" means even with stepping
enabled).  I was able to retrieve four CPU speed measurements that had
corresponding NTP loop logs.  The table below shows the perfect
correlation between linux-measured CPU speed and NTP-measured drift. 
Clearly the "real" CPU speed is somewhere around 2000.200 MHz.


measured CPU speed  |   measured drift
    (MHz)           |       (ppm)
---------------------------------------
  2000.153          |      -23
  2000.215          |        8
  2000.321          |       61
  2000.367          |       84


As I've stated before, I don't believe the oscillator is really this
unstable, but I could be wrong.  After all, my CPU measurements varied
much more than yours, especially from one run to the next.  However, I'm
still open to the possibility that linux's approach to speed measurement
is less than perfect (at least for my version of linux).  These
measurements were on a core 2 duo (2 processors) running RedHawk linux
2.6.18.8.  Hal, can you tell me which version of linux resulted in your
list of speed measurements?

I also wonder if the use of two processors has any impact on this
behavior.  I tried forcing CPU affinity for the NTP process, but it
didn't have any effect on the measured drift value.  This means that
either there truly is no difference between CPUs (as in different
speed/frequency characteristics) or I wasn't actually moving the process
between CPUs (using /proc/<pid>/affinity).  I'm assuming both CPUs have
the same oscillator, so it makes sense that they would measure the same
drift.

Thanks,
Andy





More information about the questions mailing list