[ntp:hackers] smearing the leap second

Martin Burnicki martin.burnicki at burnicki.net
Fri Jun 19 12:52:58 UTC 2015


Folks,

I think Harlan is referring to the leap smear implementation I'm 
currently working.

Terje Mathisen wrote:
> Gene Spafford wrote:
>> Can you have it optional?  If a  switch is set, all queries from
>  > higher strata get the smeared time. Unset, or queries from peers or
>  > lower strata and the exact value is used.  That would seem to be a
>  > simple fix for organizations wanting it yet not breaking the higher
>  > level service mesh.
>
> This sound like a useful approach, but I'm afraid it might be broken:
>
> I would much prefer the rule to be "clients always get the smeared time
> (when the runtime switch is active)", while we always use the true
> (baseline UTC) time for requests we send off to other servers.

Agreed. That's how I've implemented the smearing.

> I.e. this approach works for an organization with a set of S1 servers,
> all with GPS/Loran/Cs/Rb/whatever local refclocks, they would all run
> the normal ntpd deamon.
>
> At the next level you have a set of S2 servers with the ''-smear"
> option, they all contact the S1 servers using standard time, while
> supplying all clients with smeared time.
>
> I.e. this is pretty much the only feasible approach Google could be
> using internally.

My implementation actually lets the internal timing untouched, i.e., the 
OS kernel runs fully on UTC, eventually stepping the system time back by 
1 s when the leap second occurs.

You can specify a leap smear interval in ntp.conf using a new config 
option like:

leapsmearinterval 60000

so 60000 seconds before the leap second event ntpd starts to compute a 
smear offsets starting with 0, and ending with -1 s. This smear time is 
applied to both the receive time stamp and the transmit time stamp when 
answering client requests.

Leap smear is in effect if a leap smear interval has been specified. Of 
course the leap second warning bit is *not* sent in the reply packet in 
this case.

In addition, I've picked up Miroslav's suggestion in bug 2846 to send 
leap "11" (not synchronized) during the leap second.

So this can also be used on S1 servers driven by a GPS refclock.

> Trying to make a hybrid work where the S2 servers can use each other as
> peers seems overly complicated.
>
> What remains is the exact smearing approach, here I would also use the
> proven Google approach, i.e. a cosine smear over 12 hours on both sides
> of the event: This keeps the first and second order derivatives well
> below the ntpd control loop limits, while limiting the maximum absolute
> offset to 0.5 seconds.

My current implementation uses the cosine approach, but the slewing 
terminates with the leap second.

> The code patch presumably maintains an internal flag
> ("smear_in_progress") and the current offset between system time and
> smeared time, the latter could in fact be calculated on the fly for each
> request, at the risk of making timestamp retrieval a cpu hog:
>
> Since we can never need better than 32-bit fractional seconds precision,
> and us (i.e. 20-bit) is probably also more than we need, we could in
> fact precalculate a table of cosine values, one for each 64-256 seconds
> over the smear period, and then interpolate between table entries which
> would get us the required precision while using a small fraction of a us
> to do so.

My current implementation computes the smear offset once per second in 
ntp_timer, right after Pearly's code has checked and updated its leap 
second status.

The code is in ntp-stable+smear in ~burnicki on psp, but at the time I'm 
writing this I've not checked in the latest changes. Will do this later 
today.

>  >> On Jun 19, 2015, at 02:11, Harlan Stenn <stenn at nwtime.org> wrote:
>  >>
>  >> Folks,
>  >>
>  >> I'm sure I left some folks off this list who would have useful
>  >> opinions.
>  >>
>  >> I've got a patch in the queue to have ntpd smear the leap second.
>  >> ntpd would answer queries using this smeared time.
>  >>
>  >> I've got folks like Meinberg telling me they are going to
>  >> implement this because they have major customers who really want
>  >> it.
>  >>
>  >> If I implement this patch, some folks will say I'm a "bad guy".
>  >>
>  >> If I don't implement this patch, some folks will say I'm a "bad
>  >> guy". In particular, Meinberg will be unhappy because they have
>  >> customers who want this, and they don't like implementing things
>  >> that are not in our release.  They have also been very good to NTP
>  >> and NTF.  I'd rather keep them happy.

Thanks. ;-)

But this is not a precondition for our (Meinberg's) participation in 
NTF. Of course I could download the NTP tarball and apply the patch only 
locally, but this would cause quite some effort for maintenance, 
whenever the baseline code changes.

If we can get this into the main repo it will be much easier to maintain 
this, and other folks can also benefit from it, if they want.

I've recently suggested to Harlan that we include this code depending on 
a configuration option which is disabled by default.

>  >> Folks seem to understand that if they do this and "announce" this
>  >> time outside of their enterprise, it will cause problems.

Actually more and more companies start to implement their own smearing 
approach because stock ntpd doesn't support this.

I'm sure at least companies like Google and Amazon know what they are 
doing, i.e. that the smeared time differs from UTC and other NTP servers 
which don't smear, and that there may be legal considerations.

However, since there is no common solution available from stock 
everybody implements this differently, so even the smeared times from 
Google and Amazon would not match if an NTP client pulled both of them.

>  >> We also all understand that it will be much better to address this
>  >> issue in NTPv5, but that won't happen in the next week or so.

Yes, but we need a solutions for our customers *now*, not only when 
NTPv5 will be available.

>  >> I'm inclined to include this code, or something like it, and just
>  >> clearly document/publish the various pros/cons involved.
>  >>
>  >> Does anybody have strong opinions either way about this?
>  >>
>  >> Reality is biting... -- Harlan Stenn <stenn at nwtime.org>
>  >> http://networktimefoundation.org - be a member!

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de


More information about the hackers mailing list