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

Rob nomail at example.com
Thu Mar 28 09:57:37 UTC 2013

```Robert Scott <no-one at notreal.invalid> wrote:
> To achieve 11 ppm accuracy in frequency I need to have a calibration
> time interval that is about 90,000 times as long as the timestamp
> uncertainty.  If the timestamp uncertainty is, say, 100 msec., the
> calibration time period needs to be at least 2.5 hours.  That's where
> my figure of 3 hours comes from.
>
> I don't think it will difficult for a user of my app to perform this
> calibration.  All he has to do is to ensure Internet connectivity is
> turned on (it could be cell or wi-fi), hit the calibrate button in my
> app, and leave the phone on charge and go to bed.

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

Radio protocols often use polling to grant the permission to the mobiles
to send, and adaptive polling intervals depending on the recent traffic.
(or they drop clients from the polling list when there is no traffic,
offering some method for them to join again)

The result is that when you start traffic on an otherwise idle client,
you will observe roundtrip intervals like this:

time=531 ms
time=500 ms
time=540 ms
time=874 ms
time=99.7 ms
time=101 ms
time=96.3 ms
time=97.3 ms
time=101 ms
time=96.9 ms
time=102 ms
time=102 ms
time=97.4 ms
time=102 ms
time=103 ms

in this example, the first four exchanges were with the device still
in "idle mode" and only then the cell network (UMTS in this case)
decided to step down the polling interval on that client, and from
the fifth one the roundtriptime is pretty consistent.  you will need
to discard those first 4 samples and then calculate an average over
a couple more.
however, that "4" is not a constant!  it depends on parameters and
circumstances beyond your control.  so you will need to write an adaptive
algorithm that recognizes what is happening here, and send the queries
quickly enough (I would say at least two per second, maybe 4) to force
the "active user" algorithm to kick in.

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.

```