[ntp:questions] long time to report sync per leap indicator, when initial system time is set far into the future

[Mike Cook]

> Le 12 déc. 2017 à 23:17, Mike Cook <michael.cook at sfr.fr> a écrit :
> 
>> 
>> (servers #4 ff. are assigned from pool.ntp.org)
>> 
>> But, even then, from "eyeballing" the system clock it appears correct within at least 1 s,
> 
> Odd as well. Is it possible that there is another process updating the clock. I’ll try to see when I get the first clock update. 

I checked and see the clock change after four poll results returned.

Wed Dec 13 06:50:23 UTC 2017
ntpq: read: Connection refused
Wed Dec 13 06:50:28 UTC 2017
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.22.0    .M12+.           0 l    -   16    0    0.000    0.000   0.000
 192.168.1.23    .INIT.          16 u    -   16    0    0.000    0.000   0.002
 192.168.1.4     .G10.            1 u    1   16    1    0.948  -863504   0.002
 192.168.1.17    .INIT.          16 u    -   16    0    0.000    0.000   0.002
 192.168.1.18    .M8T.            1 u    1   16    1    0.978  -863504   0.002
Wed Dec 13 06:50:34 UTC 2017
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.22.0    .M12+.           0 l    -   16    0    0.000    0.000   0.000
 192.168.1.23    .GPS.            1 u    1   16    1    0.279  -863504   0.062
 192.168.1.4     .G10.            1 u    2   16    1    0.626  -863504   0.165
 192.168.1.17    .M8N.            1 u    1   16    1    0.521  -863504   0.133
 192.168.1.18    .M8T.            1 u    2   16    1    0.563  -863504   0.195
Wed Dec 13 06:36:16 UTC 2017
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.22.0    .M12+.           0 l    -   16    0    0.000    0.000   0.000
 192.168.1.23    .GPS.            1 u    -   16    1    0.307    0.003   0.072
 192.168.1.4     .G10.            1 u    1   16    1    0.564   -0.026   0.004
 192.168.1.17    .M8N.            1 u    -   16    1    0.669    0.087   0.065
 192.168.1.18    .M8T.            1 u    1   16    1    0.536    0.038   0.028
Wed Dec 13 06:36:21 UTC 2017
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.22.0    .M12+.           0 l    -   16    0    0.000    0.000   0.000
*192.168.1.23    .GPS.            1 u    1   16    1    0.279    0.020   0.044
 192.168.1.4     .G10.            1 u    -   16    1    0.563    0.017   0.058
 192.168.1.17    .M8N.            1 u    1   16    1    0.540    0.022   0.043
 192.168.1.18    .M8T.            1 u    -   16    1    0.505   -0.011   0.044

ntpq: read: Connection refused
Wed Dec 13 06:50:28 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
Wed Dec 13 06:50:34 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
Wed Dec 13 06:36:15 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
Wed Dec 13 06:36:21 UTC 2017
processor="armv7l", system="Linux/3.8.13-bone47", leap=00, stratum=2,


ntpq: read: Connection refused
Wed Dec 13 06:50:30 UTC 2017
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd 4.2.8p10 at 1.3728-o Tue Dec 12 08:45:23 UTC 2017 (1)",
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
precision=-19, rootdelay=0.000, rootdisp=0.030, refid=INIT,
reftime=00000000.00000000  Thu, Feb  7 2036  6:28:16.000,
clock=dddb4c36.78d0e3a5  Wed, Dec 13 2017  6:50:30.471, peer=0, tc=3,        <=============
mintc=3, offset=0.000000, frequency=-31.917, sys_jitter=0.000000,
clk_jitter=0.002, clk_wander=0.000, leapsec=201701010000,
expire=201706280000
Wed Dec 13 06:36:12 UTC 2017
associd=0 status=c615 leap_alarm, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.8p10 at 1.3728-o Tue Dec 12 08:45:23 UTC 2017 (1)",
processor="armv7l", system="Linux/3.8.13-bone47", leap=11, stratum=16,
precision=-19, rootdelay=0.000, rootdisp=0.000, refid=STEP,
reftime=00000000.00000000  Thu, Feb  7 2036  6:28:16.000,
clock=dddb48dc.1ed39583  Wed, Dec 13 2017  6:36:12.120, peer=9799, tc=4,      <**************
mintc=3, offset=0.000000, frequency=-31.917, sys_jitter=0.001907,
clk_jitter=0.002, clk_wander=0.000, leapsec=201701010000,
expire=201706280000

In this case where 3 or more servers are responding.
For one configured server, even though it was responding, I did not see the clock updated and the unsync'd status remained. However
I did not wait for more than a minute. 
For 2 configured servers, provided that both were responding I saw the same result as above. i.e. The clock stepped to the correct time after one reporting interval and the clock was considered sync’d on the 4th interval of 5 secs, so sometime between 15/20s. 

From the OPs observations it seems that the clock had been updated ( -g ), but that NTP had not considered the server ensemble to be sufficiently stable to use it.

May be a specific PPC architecture issue.
Could the OP test another server architecture  in the same network to check that?

"The power of accurate observation is commonly called cynicism by those who have not got it. »
George Bernard Shaw