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

From: Martin Burnicki <[email-masked]>
Date: Thu, 1 Feb 2018 10:09:46 +0100

Joe,

Joe Touch wrote:
> Can you help clarify whether this is an update to the NTP protocol or
> merely an update to the user libraries that are provided with it?
> 
> (i.e., AFAICT, smearing is a local function that doesn't involve
> synchronization per se, but does rely on NTP-like sync of time outside
> the smearing period as well as external input on planned leap events)

I was referring to the NTP reference implementation, ntpd.

While smearing is in progress on the server, the 4 byte refid field in
the NTP packets sent to the clients is modified: the first byte is 254,
and the subsequent 3 byte contain the current smear offset, scaled in a
way that a value in the range -1 ... +1 can be saved.

This has been discussed on IRC and per email by some folks when leap
smearing has been implemented.

Please keep in mind that even though there are some well-known values
for the refid field from a stratum-1 server, you can usually configure
the server to use a refid with any 4 character string.

So this is just a special "string", and during the last leap second it
turned out that it is a useful feature which lets a client detect that a
server is smearing, and what the current smear offset is.

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

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 1 Feb 2018 10:28:15 +0100

Steffen Nurpmeso wrote:
> Joe Touch <[email-masked]> wrote:
>   ...
>  |(i.e., AFAICT, smearing is a local function that doesn't involve
>  |synchronization per se, but does rely on NTP-like sync of time outside
>  |the smearing period as well as external input on planned leap events)
> 
> As far as i know nothing except the fully-blown and slow RFC 7808
> tzdist (untested) and Poul-Henning Kamp's leap DNS record idea as
> posted on leapsecs@ helps to avoid the downloading and parsing of
> the IERS leapseconds file on your own if you want to include
> leapsecond notification in a daily report, on at least systems
> which were off overnight.

I think you need to distinguish here between (stratum-1) NTP servers and
NTP clients, and it also makes a difference whether you just need to
know if a leap second has been scheduled, or what the current offset is
between UTC and e.g. TAI.

Stratum-1 servers can receive a leap second announcement flag from a
refclock, e.g. a GPS receiver, *if* both the receiver and the data
protocol used with that receiver support this.

Even though GPS receivers know the current UTC/GPS time offset
internally by design, I'm not aware of any way to get this offset from a
GPS receiver into ntpd, so with this approach ntpd can only detect when
a leap second is approaching, but it doesn't know the current UTC/TAI
offset, and thus it can only provide its clients with a leap second warning.

If a *current* leap second file is available on the server then ntpd can
figure out what the current UTC/TAI offset is, and determine if and when
a leap second has been scheduled. If I remember correctly then this is
also true for the tzdist or DNS approach.

Once the NTP server knows about an upcoming leap second, it sends the
leap second warning flag to the NTP clients, *unless* the server is
smearing, in which case the leap second warning flag is omitted from the
packets sent to the clients.

The leap second warning flag is usually sent 24 hours before the leap
second occurs, even if the NTP server knows about the upcoming leap
second months before.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 1 Feb 2018 10:37:22 +0100

Joe,

Joe Touch wrote:
> Leap seconds are introduced months in advance.

That depends on the source of information.

For a leap second file this is true, if the file is updated as soon as a
new one has become available.

GPS receivers also become aware of a scheduled leap seconds months in
advance, but the question is if and when they start sending a warning of
an upcoming leap second to the application, e.g. ntpd.

The German DDF77 long wave receiver also sends a leap second warning,
but only 1 hour in advance.

If your time source is an IRIG or similar time code receiver then the
receiver doesn't get a warning of an upcoming leap second at all. The
time just steps by inserting a second "60". Only if one of the
IRIG-compatible IEEE timecodes is used, a leap second *warning* is also
transmitted, but only a few seconds before the leap second actually happens.

So this can be pretty tricky. I've collected some information in a
presentation:
https://www.meinbergglobal.com/download/burnicki/Technical%20Aspects%20of%20Leap%20Second%20Propagation%20and%20Evaluation%20-%202015-06-23.pdf

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Steffen Nurpmeso <[email-masked]>
Date: Thu, 01 Feb 2018 19:35:18 +0100

Martin Burnicki <[email-masked]> wrote:
 |Steffen Nurpmeso wrote:
 |> Joe Touch <[email-masked]> wrote:
 |>   ...
 |>|(i.e., AFAICT, smearing is a local function that doesn't involve
 |>|synchronization per se, but does rely on NTP-like sync of time outside
 |>|the smearing period as well as external input on planned leap events)
 |> 
 |> As far as i know nothing except the fully-blown and slow RFC 7808
 |> tzdist (untested) and Poul-Henning Kamp's leap DNS record idea as
 |> posted on leapsecs@ helps to avoid the downloading and parsing of
 |> the IERS leapseconds file on your own if you want to include
 |> leapsecond notification in a daily report, on at least systems
 |> which were off overnight.
 |
 |I think you need to distinguish here between (stratum-1) NTP servers and
 |NTP clients, and it also makes a difference whether you just need to
 |know if a leap second has been scheduled, or what the current offset is
 |between UTC and e.g. TAI.
  ...
 |Even though GPS receivers know the current UTC/GPS time offset
 |internally by design, I'm not aware of any way to get this offset from a
 |GPS receiver into ntpd, so with this approach ntpd can only detect when
 |a leap second is approaching, but it doesn't know the current UTC/TAI
 |offset, and thus it can only provide its clients with a leap second warning.
 |
 |If a *current* leap second file is available on the server then ntpd can
 |figure out what the current UTC/TAI offset is, and determine if and when
 |a leap second has been scheduled. If I remember correctly then this is
 |also true for the tzdist or DNS approach.

So yes, sure, that is the status quo.  And i still do not like it,
because i sit at the end as a dumb consumer of a UTC timestamp and
need to find other ways to realize a context, just in case i need
it.  It is not that bad because TZ ships the leapseconds file and
so i can or better could give indication for dayling saving time
and also leapsecond events.  Without being online all the time
that is.  Or having a dedicated box like your company provides.

All this is very sophisticated.  I mean, not that bad no more,
right now, due to easy VHOST and clowd services, and also cheap
entry computers, but two decades back computers where, yes,
a considerable investment and indeed an active equity.  Right.
And only because at the moment that cheap stuff is not, it may
very well be at a later time again, given that stuff contains rare
earth.  And of course the gap in between poor and rich increases
indeed and the middle class and their small businesses reassigns.

I am hoping for an easy way, computational and otherwise, to
become aware of the current difference in between TAI and civil
time UTC.  For example, a DNS entry that is so easy to parse as
what Poul-Henning Kamp suggested on leapsecs@.
I do not know about the territorial p.ssings which are involved in
the NTP area, but the engineering community has finally found
their way to DNS via DTLS, DNS via TCP/TLS, since yesterday and
RFC 8314 we even have the submissions:// protocol that listens on
the "legendary" port 465 (section 7.3), so maybe a future NTP spec
will be secure via enwrap-in-*SSL and DTLS or TCP/TLS too, and
offer some optional room for a UTC/TAI offset, which i think will
or find some possible consumers.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 5 Feb 2018 16:52:00 +0100

Steffen Nurpmeso wrote:
> that is.

Basically you have 2 options:

Either you update the TZ DB on a regular basis, whenever a new version
has been released, or you use a protocol like tzdist to do this
automatically.

While the former is under your control if you're the admin of a machine
or whole network, your device is left alone if your distro / OS is out
of support, or if you look at the huge number of embedded devices which
never get a software update. These devices could at least update the TZ
/ leap second information if they can use the tzdist protocol, once this
has become more popular.

> Or having a dedicated box like your company provides.

... which provides accurate time and leap second information, but no TZ
DB updates. ;-)

> a considerable investment and indeed an active equity.  Right.

At that time there weren't much folks who cared about millisecond or
even microsecond accuracy, and the huge number of DOS-based machines
didn't even know the difference between UTC and local time. ;-)

There were no embedded devices running e.g. a *IX operating system
internally like today, where many users of siuch devices don't even even
knowing about this.

> indeed and the middle class and their small businesses reassigns.

Agreed, but how is this related to our topic?

> what Poul-Henning Kamp suggested on leapsecs@.

Again, I agree this is a clever and lightweight solution, but I don't
know if this is really implemented somewhere.

> or find some possible consumers.

I'm in no way against such new methods. Everything that makes things
easier and more reliable is highly appreciated.

Martin
-- 
Martin Burnicki

Senior Software Engineer