[ntp:questions] offset with ntpdate and ntpq ?

Uwe Klein uwe_klein_habertwedt at t-online.de
Mon Sep 1 06:06:22 UTC 2008

Unruh wrote:
> David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:
>>Stavros Milos wrote:
>>>I would like to "read" a time of each remote NTP server and compare it 
>>>to my local referential timeserver, just to examine if offset of each 
>>>remote NTP server is not too high. So, the purpose is not to synchronize 
>>>time to remote NTP servers, but to trace their time to keep a rule:
>>>  "remopte NTP server time" - "my referential NTP server time"  <  0.5s
>>"Offset" doesn't really give you this information.  If the ntpd design 
>>is valid, "offset" is either a measure of the network performance, or 
>>that ntpd has not been running long enough to work out which part of the 
>>offset is a true clock error and which part measurement variation.  If 
>>you know of a way of telling the difference between a true error and 
>>measurement uncertainty, before ntpd is able to do so, you need to 
>>submit your algorithm to the NTP community.
> Actually I have submitted such an algorithm but interest is low ( chrony
> does it much faster than does ntp) But that is irrelevant. If he has
> network errors of 500ms he has one very very weird network. For a local
> network the network errors are typically microseconds, not seconds. ( Note
> that offsets of seconds ntp will step so apparently it does know it is not
> random network errors. )
You get that kind of (wrong) offset when your machine is sitting at the
end of an ISDN line that is heavily utilised in one direction only.
This is the reason why I would like to have signaling to tell the
ntp daemon "poll now".
This can be _partly_ remedied with ( or similar )
	tinker huffpuff 160000
you will still have the clock going south on occasion.

This is a feature that is of interest to mobile platforms too
( "mobile" platforms need the "hey man there is a new door" signaling too ).


More information about the questions mailing list