On 03/29/13 15:27, Claudio Carbone wrote:
On 29/03/13 19:26, Brian Utterback wrote:
As unruh said, if there was a way to improve the accuracy of the
measurement over the network like that, NTP would already be doing it.
If so why doesn't the offset oscillate?
If NTP were a real compensation system, it should oscillate around the
setpoint.
Instead I noticed a nearly static offset, at least during the 15
minutes observation time.
This has to do with another reason that taking the average offset
doesn't help. Each data point has its own error possible as determined
by the round trip time of the polling process. For instance, if the
round trip time were 1ns, then we know that the calculated offset
between the clocks can not be in error by more than 1ns. But if it were
1 minute, then we can only say that the calculated offset is within 1
minute of the actual offset. There are some tricks that NTP uses to
eliminate the processing time from the trip time, and the result is
called the "delay" in the ntpq output. But it sets a maximum error in
calculating the offset between a system and the server.
So, what NTP does is store the last 8 polls and uses the poll that has
the smallest delay since it is more likely to be more accurate. There is
some weighting going on too, so that polls grow "stale" over time by
adding a age based correction. But if you get a single poll that has a
much shorter round trip time than usual, that same offset may end up
being displayed for several poll periods, until it either falls off the
end, one with a smaller delay comes along or the correction for its age
means that another poll is better.
You need to remember that the output of "ntpq -p" does not represent the
clock offsets as it is "now", it represents the clock offset relative to
a particular server, as it was calculated and selected at the time of
the last poll to that server.
--
blu
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. - Martin Golding
-----------------------------------------------------------------------|
Brian Utterback - Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:brian.utterb...@oracle.com
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
