Subject: Re: [art] Confirm submission of I-D draft-touch-time

From: Martin Burnicki <[email-masked]>
Date: Thu, 1 Feb 2018 11:01:40 +0100

Carsten Bormann wrote:
> Besides, the experiment already has been made in some very large sites, and site operators/reliability engineers liked the outcome.

I think it depends on the kind of application if you like the outcome. ;-)

Smearing is OK as long as applications can tolerate that the system time
is temporarily off by up to 1 s (or -0.5 s ...+0.5 s). The advantage is
that time increases monotonically all the time.

On the other hand, if applications have to rely on a more accurate time
then smearing is bad, and yes, I'm aware of the problems caused by just
stepping the system time back by 1 s when the leap second is inserted.

> No doubt, leapsecond smearing is wrong, impure, and a giant hack.
> But the previous way in which Posix time worked is all these, too, plus it loses monotonicity and has a step function.

I absolutely agree.

> We haven’t put an indication of a time scale in draft-bormann-cbor-time-tag-01 yet (draft-bormann-cbor-time-tag-00 had one, but it wasn’t fully cooked).  Besides UTC, TAI, and real-time variants of these (UTC(PTB) etc., TAI as approximated towards UTC(USNO) a.k.a. “GPS time + 19 s”, ...), it would be useful to have a smeared leapsecond time scale in there (and preferably just one).  If the IETF can be instrumental in fostering and documenting some consensus here, this would be a big win.

Haven't looked at the documents, yet, but IMO smearing should be done
locally, by the OS.

So an NTP server (or PTP grandmaster) wouldn't have to provide smeared
time. It just had to provide a leap second warning flag, as usual, and
when the clients received that warning they could determine if they
would smear the system time, or not, or provide different APIs that
return smeared time and non-smeared time.

Some time ago I discussed with some kernel guys why they don't implement
the workaround proposed by Dave Mills many years ago.

That would basically stop the system clock during a leap second and let
the the system time increase by 1 LSB (depending on the supported
resolution) whenever the system time is read by an application.

This would make sure the system time increases monotonically, but the
reply from the kernel hackers was that the execution time required to
read the system time is much longer if such comparisons/computation have
to be done, than just stepping the time back by subtracting a 1 s offset.

So also the execution time is important, and if the system clock
supports smearing the execution time is also longer than without smearing.

So IMO different APIs (e.g. the clock ID used with clock_gettime())
could alternatively provide the "legacy" time, or a smeared time.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

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
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy