[ntp:questions] NIST vs. pool.ntp.org ?

Rob nomail at example.com
Thu Mar 28 13:37:50 UTC 2013

Robert Scott <no-one at notreal.invalid> wrote:
> On 28 Mar 2013 09:57:37 GMT, Rob <nomail at example.com> wrote:
>>To achieve an uncertainty below 100ms over connections like that you
>>will need to do some clever programming where you get multiple time
>>stamps, measure the roundtriptime on each of them, and discard
>>outliers before you calculate an average.  The kind of thing that ntpd
>>already does.
> If I could use a packaged implementation of NTP I would.  But I don't
> have that option.

I understand that, I only want you to know that you need to implement a
clever filter just like in ntpd or else you will have a problem.

> Are these exchanges all with the same Time Server?  I thought good
> citizen use of these Time Servers required at least 4 seconds
> inbetween queries.  Or does the start-up polling time penalty only
> once even if every query is to a different Time Server?

That is a complicating factor.   You need to cause some traffic to
kick the link into faster action but you don't want to cause trouble
with the Time Server admin (who may have set an access rule that blocks
you when you send a burst of requests).
You can instead ping something that you know responds to pings, e.g.
send 10 requests at .25 second intervals, and then immediately request
the time from a timeserver.  The link does not look at what system
you communicate with, it only checks if there is a certain number of
packets per second to see if you are "active".

>>even then, I have seen links (e.g. over WiFi) where a stable state
>>is never reached and varying roundtriptimes between nearly zero and
>>about 200ms are seen no matter how often and how frequently you ping
>>over them.
> In those cases how asymmetric is the polling delay likely to be if I
> just take the midpoint of the polling interval, just like NTP?  I
> realize that it is "possible" to be extremely assymetric, but in
> practice?

Very asymmetric.  The access point can always transmit when it likes,
the clients have to wait for the access point to tell them that they
can have a go.  It varies widely between implementations.  It can be
like the behaviour shown for UMTS, or it can be that the access point
polls at some fixed interval (that you aren't synchronous to) so
you will see variation between 0 and that interval, only in the
direction client->server.

Maybe for your application it would be wise to check the roundtriptime
only to see if it has already fallen from some initial high value,
but not to use it in the calculation of real time (i.e. don't take
a midpoint between request and reply).
That is because excessive and variable delays are more likely to
occur on the uplink than on the downlink.

More information about the questions mailing list