[ntp:questions] What is the NTP recovery time from 16s step in GPSserver?

unruh unruh at invalid.ca
Thu Nov 1 16:25:39 UTC 2012


On 2012-11-01, David Lord <snews at lordynet.org> wrote:
> David Taylor wrote:
>> On 31/10/2012 21:04, unruh wrote:
>>> On 2012-10-31, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
>> []
>>>> NTPD is a "slow starter"!  Ideally, you will only start it once and
>>>> let it run for a few months.
>>>>
>>>> How slow is a "slow start"?.  It can take NTPD up to ten hours to
>>>> synchronize within + or - 50 nanoseconds with whatever you are using as
>>>
>>> It will never get to within 50nsec. The interrupt processing is far more
>>> variable than that. You might get to withing a few micro seconds.
>> 
>> On a recent restart from cold, the server here took about 15 minutes to 
>> get to within 250 microseconds, and about an hour to be within 10 
>> microseconds.  Ultimately it is within about 3 microseconds.
>
> I'm on NetBSD-6 and ntpd 4.2.6p5 although I don't believe the
> previous versions were any worse. The rstarts are usually within
> around 15-30 min to be better than 1 ms and replying to requests.
> I lost 7 x pcs Jun-Sept this year after local mains substation
> transformer self destructed so my system with GPS is down. That
> would be within a few usec within an hour but was sensitive to
> large temperature and load changes with nightly excursions to
> 30 usec for short periods.

Yes, ntp is slow to respond to rate changes. That is its main problem in
getting the ultimate accuracy (since rate changes due to temp changes
are probably the dominant source of inaccuracy on most systems). chrony
responds to such rate changes much faster, and keeps the time on track
with utc much better. It probably comes at the cost that the rate of the
system clock is not as well disciplined as on ntp, although that is
irrelevant if the rate keeps changing due to temp changes. what I mean
is that if your noise model is gaussian random noise on the packet
timing, then ntpd will settle down to a better rate correction than will
chrony. But that is not the dominant noise source on most systems.

>
> The example I've seen as to getting sub usec was GPS combined with
> a remote stable system clock source (from a TAPR board). I've too
> much on at the moment repairing/replacing the failed systems to
> setup the Ru clock I bought off ebay.
>
>
> David



More information about the questions mailing list