| Re: [chrony-users] gpsd, pps and chrony |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Wed, 6 Apr 2011, Ed W wrote:
I have investigated this further and in fact lpj set on the kernel
command line appears to make *no* difference to chrony's frequency
estimation... Curious.
In fact this code in tsc_init() is causing the frequency offset to vary:
tsc_khz = x86_platform.calibrate_tsc();
cpu_khz = tsc_khz;
The reason I was misled is because I was altering the calibrate_tsc
functions, which in turn generate the lpj, however, it's not actually
the lpj which is causing any effect on chrony, it's something to do with
the assignment above
Now, I was partially successful at altering the calibrate_tsc to make it
more stable at boot, but I can't get it reliable to the tick every
single time unless I spend perhaps 1-2 secs calibrating at boot...
(which isn't really sensible)
Quick poll:
Who finds their boot sequence gives a rock solid "Detected xxxKhz
processor" line at bootup, and similarly gets a rock solid "Bogo mips"
and "lpj=yyy" line at every boot? (remember, zero variation is the
question?)
Followup question for someone smarter than me (Miroslav..):
- I see a clear connection between my cpu Mhz as reported in say
/proc/cpuinfo (unknown if this source is reliable when processor
powersave in use?) and the stable chrony tracking parameters
- Assuming it's not just an anomoly which affects me, could chrony
additionally store the detected kernel Mhz with the tracking params and
in the case that the next boot uses different detected Mhz, adjust the
initial tracking params to compensate?
I do not think that chrony is the place to try to solve kernel problems-- it
loads it down, potetnially introduces bugs, etc. You need to talk to the
kernel people not to chrony.
At least in my case the above proposal will significantly increase my
initial frequency estimate by around 100-150 ppm (!!) and because I have
only intermittently connected ntp this will help enormously...
Having googled a bit I see that the basic problem has been found by
others, eg this (unsuccessful) attempt at a kernel hack in this thread:
http://osdir.com/ml/linux-kernel/2009-05/msg05048.html
I'm quite surprised that others don't see this gross variation that I
do? For me at least I get no value at all from chrony's saved tracking
params because chrony is tracking an average offset of around 130ppm,
but the bootup variation is some 100+ ppm around that offset? Do others
get less variation with each boot?
I get around 50PPM variation on some of my machines. On others with newer
kernels I get much less, but perhaps they are using some other clock than tsc
by default.
Do you understant how it calibrates the tsc anyway? The only clock it has is
the rtc. Does it use that? The problem is that the interrupt processing by the
rtc has been broken for about 5 years now-- the interrupt is dumped on the NMI
and cannot be used. Thus the rtc gets polled. But polling is notoriously
inexact. This IF they use the rtc to get at the timing I am not at all
surprised that it is way out.
Thanks - seem to be homing in on the problem at least!
---
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.