[time-nuts] Graphs

Magnus Danielson magnus at rubidium.dyndns.org
Mon Jan 2 10:00:46 EST 2017


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 

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.


More information about the time-nuts mailing list