Leap second quirk
Two of my systems injected leap seconds at the end of Aug and Sep.
A couple of others didn't.
I thought I saw some discussion of this, but I can't find it. Has
anybody else seen this? Was I dreaming about seeing something here?
Is the bug in the Linux kernel for not waiting until December, or
should ntpd wait until December before telling the kernel?
I think both systems are/were running a recent ntp-dev on a reasonably recent
Linux (2.6) kernel.
I'm watching (noselect) both systems from a third box that didn't have
One did what I expect. It's clock was off eby a second. After about 20
minutes it stepped back.
I haven't sorted out what the other one did yet.
These are my opinions, not necessarily my employer's. I hate spam.
Re: Leap second quirk
Hal Murray wrote:
> Two of my systems injected leap seconds at the end of Aug and Sep.
> A couple of others didn't.
> I thought I saw some discussion of this, but I can't find it.[/color]
In August what seems to be a bug in SIRF chipset GPS receivers was discussed
here. Look for "UTC Time from NMEA receiver one second behind DCF". This
link [url]http://www.megapathdsl.net/~hmurray/ntp/leap-gps3.gif[/url] shows the
intermittent one second lag. It seems ntp is innocent since the wrong data
is already in the NMEA data sent by the GPS receiver.
Hope this helps.