[ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7
martin.burnicki at meinberg.de
Fri Nov 29 12:08:46 UTC 2013
David Woolley schrieb:
> On 28/11/13 08:34, Martin Burnicki wrote:
>> In such case ntpd only had to make the disciplined system time available
>> on the network, e.g. using the local clock driver with stratum-0.
> I believe this is the case for which the typical sample configurations
> apply. They don't use stratum zero, although they don't use as high a
> number as for a time island. They don't use zero because, with this
> configuration, ntpd doesn't know when the clock has failed, whereas,
> with a real clock driver it should.
Basically I agree.
The scenario I meant is exactly when ntpd is unable to access the
hardware refclock directly, and thus is unable to determine if the
refclock hardware is OK, or not.
The Windows system time might be disciplined by a different time
adjustment service, and how accurately this is done depends on the
implementation of that service.
For example, if you use one of our (Meinberg) GPS PCI cards under
Windows then the time adjustment service coming with our driver package
is used to discipline the Windows system time. This is at least as
accurately as can be done by ntpd, but uses a faster control loop, and
can even cause some action (notification or whatever) when the GPS
receiver goes out of sync or gains sync again.
Of course the drawback is that ntpd has no information about the status
of the hardware refclock. However:
- If there's only a single such server on the network then the clients
usually should still follow this server even if the external time
adjustment service stops disciplining the system time. This matches the
original idea of the local clock.
- If there are several such servers on the network and on one of them
the Windows system time stops to be synchronized by the external program
then real NTP clients which poll all those servers should identify the
failing machine as false ticker as soon as the time on this machine
starts to drift away.
If all the NTP clients run ntpd then if probably doesn't matter much if
the local clock's stratum is 0 or 12. However, there are NTP client
implementations out there which expect a certain "good" stratum from
their server or would refuse it otherwise.
So IMO it's a good idea to use the local clock with stratum 0 in such case.
More information about the questions