Date: Tue, 3 Jan 2006 21:17:13 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: "M. Warner Losh" <imp@bsdimp.com> Cc: current@freebsd.org Subject: Re: FreeBSD handles leapsecond correctly Message-ID: <20060103101713.GI42228@cirb503493.alcatel.com.au> In-Reply-To: <20060103.015516.21274860.imp@bsdimp.com> References: <m3psnaenl9.fsf@merlin.emma.line.org> <20060102.221046.75255380.imp@bsdimp.com> <20060103061752.GE42228@cirb503493.alcatel.com.au> <20060103.015516.21274860.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2006-Jan-03 01:55:16 -0700, M. Warner Losh wrote: >In message: <20060103061752.GE42228@cirb503493.alcatel.com.au> > Peter Jeremy <PeterJeremy@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 "common" statement. >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. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060103101713.GI42228>