> Le 11 déc. 2017 à 12:49, Stephan E. <[email protected]> a écrit :
>
> I want ntpd 4.2.8p10 to sync to public servers, then serve time to a local
> network. It is running with '-g' because initial system time on the host can
> be far off. I observe that, when initial system time of the host was set > 5
> minutes into the future, the time it will take ntpd to report a synced leap
> second to its clients approaches the time of that initial offset. E.g., when
> the initial time was erroneously set 24 hours into the future, ntpd will take
> approximately 24 hours to report a synced time in the LI field to its
> clients, and they will reject to sync to my host during that period.
>
> Is this behavior to be expected, or is it likely that am I doing something
> wrong? I would agree that it is a weird scenario, but it can not be ruled out
> in my application.
>
I am pretty sure that this is expected behavior and a configuration error.
I have tried and failed to reproduce this in either 4.2.8p10 or 4.2.8p9 UNLESS
there are NOT ENOUGH sufficiently stable servers available at start up.
That is to say, that if their reach values does not tend to 377.
for example if I have only 2 servers configured and only one is stable such as
here:
Tue Dec 12 08:19:11 UTC 2017
remote refid st t when poll reach delay offset jitter
==============================================================================
time-c-g.nist.g .NIST. 1 u 5 16 275 95.193 -398059 0.047
india.colorado. .NIST. 1 u 14 16 377 130.526 -398062 0.050
The leap indicator will remain 11, i.e. unsynchronized
Tue Dec 12 08:19:03 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
Tue Dec 12 08:19:08 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
Tue Dec 12 08:19:13 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
Tue Dec 12 08:19:18 UTC 2017
So you should make sure that you select servers that have good connectivity (
closer is better ) and use a minimum of 5.
So to debug this, change your date , restart ntpd with just -g and then
monitor the server status. If the servers are showing poor connectivity,
change/add .
Hope this helps
> A workaround appears to be running with '-g -q' first, in which case ntpd
> will sync and exit under 1 minute; then run without either option, in which
> case the LI field will report a sync within approx. 300s.
>
> Do you think the workaround is suitable, or am I inviting e.g. errors in leap
> second handling?
> _______________________________________________
> questions mailing list
> [email protected]
> http://lists.ntp.org/listinfo/questions
"The power of accurate observation is commonly called cynicism by those who
have not got it. »
George Bernard Shaw
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
