NTP Performance

[Hal Murray]

Also, what does this mean and is it a problem (it's an ERR level)? I'm
seeing it on both servers.

2019-11-23T01:49:33.497786-06:00 ntp1 ntpd[28568]: CLOCK: ts_prev 1574495373 s 
+ 497394102 ns, ts_min 1574495373 s + 497388500 ns
2019-11-23T01:49:33.497936-06:00 ntp1 ntpd[28568]: CLOCK: ts 1574495373 s + 
497388500 ns
2019-11-23T01:49:33.498001-06:00 ntp1 ntpd[28568]: CLOCK: sys_fuzz 92 nsec, 
prior fuzz -0.000000043
2019-11-23T01:49:33.498073-06:00 ntp1 ntpd[28568]: CLOCK: this fuzz 
-0.000000020
2019-11-23T01:49:33.498129-06:00 ntp1 ntpd[28568]: CLOCK: prev get_systime 
0xe183630d.7f564f2e is 0.000022246 later than 0xe183630d.7f54d9f6

------

It means something is broken.  Could be our code.  Could be something else.

The idea is that you can only read the clock with so much granularity, so it 
randomizes the bottom bits.  I think that made sense when system clocks did ms 
ticks but I'm not so sure with modern clocks.  The code (leftover from ages 
ago) uses the time to read the clock as the grain size rather than a ns that 
you get from most systems.  (Raspberry Pi-s have a slow clock.)

The code that reads the clocks works hard to make sure that fuzzing the bottom 
bits doesn't make time go backwards.  That logging is what happens when things 
go wrong.

What sort of hardware/OS are you running on?


-- 
These are my opinions.  I hate spam.