FreeBSD handles leapsecond correctly
PeterJeremy at optushome.com.au
Tue Jan 3 02:17:23 PST 2006
On Tue, 2006-Jan-03 01:55:16 -0700, M. Warner Losh wrote:
>In message: <20060103061752.GE42228 at cirb503493.alcatel.com.au>
> Peter Jeremy <PeterJeremy at optushome.com.au> writes:
>: Actually, I'd suggest that you can't build a system that keeps any
>: sort of accurate time without a connection to the outside world or a
>: quite substantial budget. If you assume a leap second every 5 years
>: then the difference between UTC and TAI is about 6e-9 - being able
>Actually, that's wrong. If you assume a leap second every 18 months
>you'd be better off, in the long run.
That brings you into the high-end OCXO range I think - though I was
thinking in terms of systems which needed to distinguish UTC and TAI
without any external references.
>: to tell the difference requires an atomic clock - which isn't common
>: in embedded systems.
>Unless those embedded systems deal with time.
Timing products are obviously a special case. I still stand by my
>every time includes cases where the GPS reciever has been a powered
>down spare for the past 9 months and therefore has no notion of the
>leap seconds that have accumulated. This means it has to have an
>extra long startup period while the GPS receive gets a new almanac.
>This long wait is irritating to a customer, as you might imagine.
In this case, the problem is that the connection to the outside world
exists but does not provide the required information (UTC/GPS offset)
in a timely manner. You could suggest that if the correct time is
that critical to the customer, maybe they should be using hot-standby,
not cold-standby spares :-). Does Galileo handle this any better?
I now have a much better understanding of the background to your stance
on leap seconds.
More information about the freebsd-current