Does anybody here have additional references to suggest for the leap second “smear” (smoothing)?
Thanks! Rob — > Begin forwarded message: > > From: Rob Seaman <[email protected]> > Subject: Re: [ntpwg] Proposed REFID changes > Date: July 21, 2015 at 6:38:46 AM MST > To: Martin Burnicki <[email protected]>, Ulrich Windl > <[email protected]> > Cc: [email protected], Hal Murray <[email protected]> > > On Jul 21, 2015, at 12:46 AM, Martin Burnicki <[email protected]> > wrote: > >> Ulrich Windl wrote: >> >>> Well, "smear" is not a technical term with clear semantics, so the obvious >>> interpretation is anything that changes the clock frequency from the >>> correct frequency IMHO. >>> Is there a true technical specification of "smear" or "smeard lepsecond"? >> >> I have not seen a technical specification, but I think in the context of >> this discussion "slew" means that a client adjusts its system time >> gradually, to apply a leap second or another correction, the slewed system >> time is sent out in reply to client requests, and also other applications >> running on the slewing machine see the slewed system time. >> >> Contrarily, "smearing a leap second" as I've implemented it for ntpd means >> that all the internal timing is unchanged, i.e. ntpd passes the leap second >> warning to the kernel, the kernel steps the time back to insert a leap >> second, etc. Only the time put into the reply packets on client requests is >> modified by a "smear offset" which increases from 0 to -1 s over the smear >> interval, so that the sent time matches UTC again after the end of the leap >> second. >> >> Martin > > Presumably most here are familiar with this excellent analysis: > > > http://developerblog.redhat.com/2015/06/01/five-different-ways-handle-leap-seconds-ntp/ > > I’ll join Ulrich and Martin in wondering if there are other technical > specifications we should consult? > > The first coherent description by Markus Kuhn used the term “smoothed leap > seconds”, and I think smoothing is a better description of the operation: > > http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/ > > Perhaps Kuhn’s terminology (and formalism) would make a better foundation for > NTP than Google’s? > > > http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html > > Underneath both of these, with each leap second as announced by IERS Bulletin > C: > > http://datacenter.iers.org/eop/-/somos/5Rgv/getTX/16/bulletinc-049.txt > > There is a corresponding swing in the opposite direction of DUT1, e.g., > > DUT1 = UT1-UTC went from -0.7s to +0.3s, > as UTC-TAI went from -35s to -36s: > > from: http://datacenter.iers.org/eop/-/somos/5Rgv/getTX/17/bulletind-123.txt > to: http://datacenter.iers.org/eop/-/somos/5Rgv/getTX/17/bulletind-124.txt > > It is more correct to view UTC as a standard in units of tenth-seconds. This > is what it provides formally as an approximation to UT1. > > So another way to look at smoothing / smearing is as spreading that 10 step > adjustment (in tenth-seconds) out over some period of time. At the nominal > NTP slew rate of 0.5 ms per second, each tenth-second step would take 200 > seconds to accomplish. How NTP (or other software) explicitly implements > smoothing of leap seconds (e.g., linear versus cosine, etc.) is a matter for > discussion before the next leap second. One hopes Martin’s prototype > generated some good field data to analyse from the latest leap second. > > Perhaps the word “smear” should be reserved for Google’s implementation? A > synonym for smooth is “continuous”, and this is the word the ITU has chosen > to emphasize as a key feature needed for UTC. Implementing smoothed / smeared > leap seconds is one way to achieve this goal. > > Rob Seaman > Network Time Foundation > [email protected]
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
