Losing time like crazy (1s short per 10s) - how to investigate?

[Martin S. Weber]

On 2016-08-16 13:20:02, Martin S. Weber wrote:
> This is on FreeBSD 10.3-RELEASE-p7. I've only noticed this today,
> so I'd suspect this is post the p7 update (although I haven't
> investigated in that direction yet). I'm losing roughly a second
> per 10 seconds wall time.  Look at this crazy guy:
> 
> # ntpd -q ; sleep 10; ntpd -q                                                                
> 16 Aug 13:12:52 ntpd[48425]: ntpd 4.2.8p8-a (1): Starting
> (...)
> 16 Aug 13:12:54 ntpd[48425]: ntpd: time set +0.891676 s
> ntpd: time set +0.891676s
> 16 Aug 13:13:04 ntpd[48426]: ntpd 4.2.8p8-a (1): Starting
> (...)
> 16 Aug 13:13:06 ntpd[48426]: ntpd: time set +1.218972 s
> ntpd: time set +1.218972s
> 
> This is a CRAZY amount of skew. I've never noticed this before --
> (...)

Note, with (kernel) p4 (userland) p6 (I freebsd-update'd rollback) 
this does not happen:

# ntpd -q ; sleep 10 ; ntpd -q                                                                                
16 Aug 13:24:05 ntpd[1198]: ntpd 4.2.8p8-a (1): Starting
16 Aug 13:24:05 ntpd[1198]: Command line: ntpd -q
16 Aug 13:24:05 ntpd[1198]: proto: precision = 0.260 usec (-22)
16 Aug 13:24:05 ntpd[1198]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature
16 Aug 13:24:05 ntpd[1198]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2016-12-28T00:00:00Z last=2015-07-01T00:00:00Z ofs=36
16 Aug 13:24:05 ntpd[1198]: Listen and drop on 0 v6wildcard [::]:123
16 Aug 13:24:05 ntpd[1198]: Listen and drop on 1 v4wildcard 0.0.0.0:123
16 Aug 13:24:05 ntpd[1198]: Listen normally on 2 em0 10.10.1.79:123
16 Aug 13:24:05 ntpd[1198]: Listen normally on 3 lo0 [::1]:123
16 Aug 13:24:05 ntpd[1198]: Listen normally on 4 lo0 [fe80::1%2]:123
16 Aug 13:24:05 ntpd[1198]: Listen normally on 5 lo0 127.0.0.1:123
16 Aug 13:24:05 ntpd[1198]: Listening on routing socket on fd #26 for interface updates
16 Aug 13:24:06 ntpd[1198]: ntpd: time slew +0.008026 s
ntpd: time slew +0.008026s
16 Aug 13:24:16 ntpd[1201]: ntpd 4.2.8p8-a (1): Starting
16 Aug 13:24:16 ntpd[1201]: Command line: ntpd -q
16 Aug 13:24:16 ntpd[1201]: proto: precision = 0.255 usec (-22)
16 Aug 13:24:16 ntpd[1201]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): good hash signature
16 Aug 13:24:16 ntpd[1201]: leapsecond file ('/var/db/ntpd.leap-seconds.list'): loaded, expire=2016-12-28T00:00:00Z last=2015-07-01T00:00:00Z ofs=36
16 Aug 13:24:16 ntpd[1201]: Listen and drop on 0 v6wildcard [::]:123
16 Aug 13:24:16 ntpd[1201]: Listen and drop on 1 v4wildcard 0.0.0.0:123
16 Aug 13:24:16 ntpd[1201]: Listen normally on 2 em0 10.10.1.79:123
16 Aug 13:24:16 ntpd[1201]: Listen normally on 3 lo0 [::1]:123
16 Aug 13:24:16 ntpd[1201]: Listen normally on 4 lo0 [fe80::1%2]:123
16 Aug 13:24:16 ntpd[1201]: Listen normally on 5 lo0 127.0.0.1:123
16 Aug 13:24:16 ntpd[1201]: Listening on routing socket on fd #26 for interface updates
16 Aug 13:24:17 ntpd[1201]: ntpd: time slew +0.007526 s
ntpd: time slew +0.007526s

So, jumping to conclusions, p6->p7 makes all the difference.

This is the skew since starting to write THIS email:
16 Aug 13:26:26 ntpd[1251]: ntpd: time slew -0.005940 s

Looks way more reasonable to me.

Time to PR?

Regards,
-Martin