[ntp:questions] NTP absolute accuracy?
unruh-spam at physics.ubc.ca
Sun Nov 1 08:28:24 UTC 2009
David Lord <snews at lordynet.org> writes:
>> David Lord <snews at lordynet.org> writes:
>>> David J Taylor wrote:
>>>> "Unruh" <unruh-spam at physics.ubc.ca> wrote in message
>>>> news:qg_Gm.50009$Db2.46585 at edtnps83...
>>>>> "David J Taylor"
>>>>> <david-taylor at blueyonder.not-this-bit.nor-this.co.uk.invalid> writes:
>>>>>> "David J Taylor"
>>>>>> <david-taylor at blueyonder.not-this-bit.nor-this.co.uk.invalid> wrote in
>>>>>> message news:%XQGm.126$Ym4.58 at text.news.virginmedia.com...
>>>>>>> "Unruh" <> wrote in message news:34JGm.50898$PH1.36449 at edtnps82...
>>>>>>>> Note that chrony will give you a factor of 2 or three improvement over
>>>>>>>> ntp in the errors, assuming that the roundtrip is equally split on
>>>>>>>> Linux or BSD.
>>>>>>> For those without wide-bandwidth academic connections - those folks on
>>>>>>> cable or ADSL - how good is an "equal split round trip" assumption?
>>>>>> Thanks, David, David and Jan. A few milliseconds is what I had
>>>>>> so if you are on a consumer line, what implications does that have for
>>>>>> unruh's comment?
>>>>> Which comment?
>>>> The one I quoted:
>>>> "Note that chrony will give you a factor of 2 or three improvement over
>>>> ntp in the errors, assuming that the roundtrip is equally split on
>>>> Linux or BSD."
>>>> On consumer-grade circuits the assumption about equal round trip is
>>>> unlikely to be valid.
>>>> I hope that David Lord can make some tests, and I await the results with
>>> Both fileserver using ntpd and desktop using chrony had only my
>>> local ntp servers as sources so I've restarted both with three
>>> remote sources, one common source at my isp, and alternate
>>> sources from two different sites.
>>> What I'm most interested in is the effect of temperature as it's
>>> one of two periods in year that gets largest temperature
>>> variations and I've already had to restart the servers as ntpd
>>> was unable to keep up with the higher minpoll values I had set.
>>> I'm now not quite sure how best to compare stats from chrony vs
>> Well, the way I did it was to attach a GPS PPS to the computer and use the offset
>> between it and the system time as a measurement of the accuracy.
>> (the gps was NOT used as a source for eitehr ntp or chrony).
>How do you get the time difference between your GPS and system
I wrote a parallel port interrupt routine ( well adapted on) which read the PPS
interrupt and time stamps it. Ideally that timestamp should be exactly on the
second. It is usually off by a few tens of microseconds. That is the time
>At the moment there only seems to be 100us between offsets and
>apart from this being insignificant I wouldn't know which was
>nearer to ntp time.
?? sure you would the kernel time is ntp time. The offsets are the difference
between the time ntp gets from sending out and receiving back a packet from the
remote site. This is not "ntp time" That reading goes through the clock filter,
and then is fed into the feedback loop to disciple the computer clock. That
computer clock time is the closest one can come to something called ntp time.
Unlike chrony, ntp does NOT use the time readings from the remote site to do a
best estimate of the true time, and then drive the kernel time toward that. It
assumes at each reading that the output of the clock filter IS the best estimate
of the the true time, and slowly drives the clock to minimize that. Slowly means
that in the end, the time ntp approaches is a sort of mean of those readings.
Chrony on the other hand uses from 3 to 60 of thepast readings to find the best
estimate of what the true time now is, and finds the difference between the system
clock and that true time. It then corrects for that difference both in offset and
rate. It is a very different philosophy.
>My adsl connection has also been off already for 30 minutes
>after I'd set this up. One of my servers that gets time from
>MSF and also has both test systems as sources. Both test
>systems also have the common source of my isp's timeserver
>so I'm expecting to get something meaningful from that.
The problem is that I have no idea what the accuracy of any of those items is.
YOur ISP's timesever may be a stratum 7 getting time from a bunch of bozos. Or it
may be stratum 1 getting its time from a well implimented GPS clock.
You are interested in the difference between your computer time and true UTC. the
only way you will get that is by having a local source of true time ( eg a GPS
with a 1usec or so accuracy).
I used a GPS 18LVM, but of course even there I am not sure that the internals of
the GPS receiver do not introduce microsecond sized time errors. I have never
calibrated my GPS against some better true time standard.
>I might be able to get GPS to both systems but not for a while.
One GPS receiver should be able to be split to supply time to both machines to
More information about the questions