[LEAPSECS] technical specifications pertinent to smoothing leap seconds

[Rob Seaman]

Does anybody here have additional references to suggest for the leap second “smear” (smoothing)?

Thanks!

Rob
—

> Begin forwarded message:
> 
> From: Rob Seaman <seaman at noao.edu>
> Subject: Re: [ntpwg] Proposed REFID changes
> Date: July 21, 2015 at 6:38:46 AM MST
> To: Martin Burnicki <martin.burnicki at meinberg.de>, Ulrich Windl <Ulrich.Windl at rz.uni-regensburg.de>
> Cc: ntpwg at lists.ntp.org, Hal Murray <hmurray at megapathdsl.net>
> 
> On Jul 21, 2015, at 12:46 AM, Martin Burnicki <martin.burnicki at meinberg.de> 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
> seaman at nwtime.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20150721/e7340d58/attachment.html>