[ntp:questions] ntpd on busybox ARM system not keeping time with server

Harlan Stenn stenn at nwtime.org
Wed May 19 01:36:29 UTC 2021


On 5/18/2021 5:57 PM, Jakob Bohm wrote:
> On 2021-05-18 13:56, David Woolley wrote:
>> On 18/05/2021 12:26, Andreas Schick wrote:
>>> server 127.127.1.0              # local clock (LCL)
>>> fudge  127.127.1.0 stratum 10   # LCL is unsynchronized
>>
>> Delete these lines.  As described, this system is not suitable as a
>> time server, and including these lines on a pure client can actually
>> frustrate synchronisation. This fake server is likely to vote against
>> the genuine server.

Not if the failover local clock setup configuration is done properly.

> Perhaps the "tos orphan" option is a better way to make ntpd continue
> after loss of all time sources.

Yes, orphan mode is the preferred alternative to local refclocks.

> Maybe some option to force treating the Windows server as stratum 12,
> even if it looses outside synch and reports itself as stratum 16.

I haven't read the messages leading up to this.  If the windows server
is running ntpd it can easily be configured to play an appropriate role
at an appropriate stratum in the collection of local timeservers.  This
could be a local refclock, or better, it could be an appropriate orphan
mode server candidate.

>>> server  192.168.101.2
>>
>> This appears to be the machine itself, so it will be voting that's its
>> own time is correct.  Delete it.
>>
>> Windows machines can vary from fair to atrocious as time servers.  A
>> workstation running a default configuration of w32time will be at the
>> atrocious end.
> 
> Fortunately, this is reportedly a server, which means it will keep time
> with a somewhat coarse granularity and include a battery backed TOY
> (Time Of Year) clock to keep time even across power outages.
> 
> W32Time in server mode has a tendency to fluctuate about +/- 10ms from
> the time sources.  It is designed to provide an SNTP time source for
> Kerberos clients that need to stay within +/- 5 minutes of the Kerberos
> KDC.
> 
>>
>> You should make sure that the ARM starts in the right ball park, by
>> either using a file timestamp to record the time at, or close to,
>> shutdown, or, as a last resort, setting a fixed time that isn't too
>> far from reality.
> 
> Perhaps using the sntp program to do initial synchronization to the
> server machine (as a better alternative to ntpd -g).

People keep saying this, and if the intent is to run ntpd on the box it
should not be needed.  Even around "era" rollovers.  I'd love to clearly
understand what the (alleged?) problem is, because if there is a corner
case where this really is a problem I want to see that case fixed.

> Enjoy
> 
> Jakob

-- 
Harlan Stenn <stenn at nwtime.org>
http://networktimefoundation.org - be a member!


More information about the questions mailing list