| Re: [chrony-users] Inaccurate jiffy calculation at boot (x86 & 2.6.37) |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Mon, 4 Apr 2011, Ed W wrote:
Hi
That was a Linux problem in the intermediate Linux 2.6 kernels. I think,
but
am not sure, that this has been fixed relatively recently.
Do you think you could help dig up some reference to this? I'm
struggling to find anything?
No-- it came from lurking on the net a few years ago, and seeing my own
systems having trouble with massive ( 50PPM) change in rates from one boot to
the next.
I think that some of the other time sources (hpet,...) are better.
Note I have no problem with applying my own patches - the relevant file
looks like it has a fair number of tuneables, just not sure what I'm
fiddling with?
No. IF chrony has a reasonable source of time, it will converge rapidly
to the
new drift rate. If it does not, it will drift due to the large change in
the
drift rate of the clock. Chrony cannot fix a broken clock if it has no
outside
source of time.
The only source I have (all the time) is my RTC? The RTC is actually
showing variation in the 1-2ppm range range, so quite a chunk better
than my tsc estimate...
1-2ppm is of course huge usually.
OK, that is pretty recent. The problem is that the linux kernel people
broke
the initial rate calibration of the clocks.
The code seems to be in init/calibrate.c, however, a quick git log shows
very little activity in there and certainly nothing obvious for the last
few years? Can you give me a hint on where to look?
Chrony DOES use the rtc to initially set the clock. It also uses the drift
rate of the rtc to try to correct that. It is not clear how useful that is,
since the drift calculationof the rtc is done when the rtc is hot, and the
actually drifting is done when the rtc is cold (computer switched off)
I understand that chrony uses the initial rtc time, but it doesn't seem
to use the RTC for anything else? NTP allows you to use the RTC as an
input source, which would be useful in my case
It operates the opposite way around-- chrony uses the system to calibrate the
rtc. No there is no way to use the rtc to do the system time. However you
could presumably set up a little program to read the rtc properly, and then
use the shm refclock to set the system time from the rtc.
Again, one problem is that the rtc "second" turnover, whic his supposed to
trigger an itnerrupt, did not work properly on the more recent kernels-- if
the system has an hpet, the rtc interrupt was rerouted into the NMI I believe,
which cannot ( or is not) used to trigger the rtc interrupt.
I think the issue here is getting the processor TSC even vaguely
consistent from boot to boot. I can set it through boot params, but
this isn't desirable..
Yes. I have no idea why the tsc calibration is now so terrible. It used to be
( 2 yeas ago) great. and then something changed.
I have just fiddled with a few of the tunables in calibrate.c, but I
don't seem to have made any improvement...
Do you have any otehr possible time sources then TSC?
$ cat /sys/devices/system/clocksource/clocksource0/available_cloc
ksource
tsc
Ed W
---
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.
--
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
---
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.