Hal!
Good work!
On 01/02/2017 01:09 PM, Hal Murray wrote:
Here is data from a system using Google's NTP servers.
http://users.megapathdsl.net/~hmurray/time-nuts/leap/ntp-goog-leap.png
The Offset is the view from another system. The drift is from the system
itself.
Google said 13.9 uSec/sec. That matches the step in the drift.
Note the overshoot at the end of the smear. It's about 50 ms. There is a
similar blip at the start of the smear, but it's harder to see when it's
riding on top of the sloped line.
There is a smoothed initial end and attempt to do it at the end, but
they cross-over is too late as it closes the loop again so it leaves some
The NIST UT1 server smeared the second over a whole day. ??
http://users.megapathdsl.net/~hmurray/time-nuts/leap/UT1-SF-leap.png
That's the consequence of Judah Levines approach to interpolate between
the projected UT1 offsets, which is estimated per day.
Somebody asked about systems that "freeze" the clock for a second. Linux,
NetBSD, and FreeBSD all stepped the clock back. An OpenBSD system was off by
a second for about 4 hours.
Oups. There is still things to be done.
The NTP kernel module actualy knows about the leap second, so if you
also readout the data from the kernel you can get correct date. It's a
matter of doing the coding. We've done that at work and it was fairly
trivial.
There used to be a bug/misfeature in glibc for Linux which didn't expose
the new interface. This was due to the misconception that libc would
know and kernel headers should be supplied by libc rather than with the
kernel. Ah well. It works if the libc is updated with the kernel, but
obviously it wasn't.
Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
