Re: [Ntp] [EXT] Re: Re: [EXTERNAL] Re: Re: Consensus call: NTPv5 and leap second smearing

[Martin Burnicki <[e-mail]>]

Ulrich,

Am 17.07.23 um 12:24 schrieb Windl, Ulrich:
> Hi Martin (and others),
> 
> thanks for trying to explain. However I have some issues still:
> " If the software becomes aware of a scheduled leap second, it has to decide to which "consumer" it has to forward the warning, and to which not.":
> How will a server know a "consumer" is another server or a client?

If you write your software, you need to know what to interact with.

If the "consumer" is the OS kernel, the developer needs to know what the 
kernel expects. IIRC, if the Linux receives a leap second warning, it 
inserts (or deletes) the leap second at UTC midnight at the end of the 
current day, so the time synchronization software must NOT send a leap 
second warning to the kernel more than 24 s in advance.

If the "consumer" is a specific protocol, you may either have specified 
this in some specs, or according to "best practices" or long-existing 
implementations.

For example, IIRC, the PTP specs say that the lkeap second warning is to 
be sent to the clients on y 12 hours in advance.

For ntpd it's been good practice for many years to send it up to 24 h in 
advance (not sure if that's also specified in some RFC).

Upon reception of a leap second warning, you also have to evaluate the 
trustwortiness of potential sources, and how long in advance they even 
can probide a leap second warning.

For example, if you have a current leap second file, you can know about 
12 months in advance if a leap second has been scheduled, but you'd only 
start to pass the warning on to the OS kernel in less than 24 hours 
before the event.

If you have a GPS receiver, you know about 6 months in advance if a leap 
second is approaching. However, it depends on the drivers/interfaces of 
the NTP software if and when the qwarning is passed on the internal 
algorithms of the time synchronization software. For example.

AFAIK the original NMEA sentences don't provide a way at all to pass a 
leap second warning e.g. to ntpd (correct me if new NMEA versions 
support this).

Other interfaces like ntpd's parse driver only start to pass the leap 
second warning to the main routines about 24 houtrs ago (IIRC).

If you only have a DCF77 source, the leap second warning is only 
available for 59 minutes before the event. This should be be sufficient 
to properly handle the leap second on the machine to which the DCF77 
server is connected, but this may or may not be sufficient if the 
warning has to be passed down severel levels of NTP stratums, each of 
which have a large polling interval.

If the time source of your primary NTP server is an IRIG-like time code, 
your ntpd won't even seen a leap second announcement if the time code is 
one of the usual IRIG formats like IRIG-B122. These formats can support 
a leap second where the enumerated time contains a second "60", but the 
evaluating software can only see *afterwards* that a leap second has 
occurred.

Only the IRIG-like time codes like IEEE 1344 and IEEE C37.118 provide a 
leap second warning bit that is set in advance to announce an 
approaching leap second. However, the announcement interval specified 
for the time code is only 10 seconds, so while ntpd may still detect the 
warning and pass it on to the OS kernel, it is in most cases too late to 
pass the warning on to NTP clients which poll in 64 s or even longer 
intervals.

So there's much more to keep in mind, and you have to look at the whole 
chain of leap second warning propagation to see if this will work or not.

The methods specified in the NTP RFCs are fine. Most of the "leap second 
problems with NTP" were in fact problems with the OS kernels which 
simply step the time back, problems that occurred in the kernel *when* 
the time was stepped back, and problems with applications that failed 
*because* the OS kernel just stepped the time back.

> On " No, a 3 second interval across a leap second where the server claims to
> be unsynchronized is not counter-productive. It just helps to get the
> clients across that event more smoothly.":
> As said in earlier messages, what will a (simple) client do when it queries the time around 0:00 UTC, receiving a UNSYNC from all (i.e. compliant) servers? The client cannot assume that the servers will change to SYNCED within three seconds. In contrast if the clients would receive the leap status, it SHOULD apply the bits correctly to the time information received. That could mean to re-query the time a second later (when the LI is expected to be "00"). Still, both "solutions" could trigger some query storm around 0:== UTC when a leap event happens.

As I said, that can happen for all dumb clients that query only once.

What do they do if a UDP packet gets lost and they receive no reply at all?

What do they do if they query a server that is not yet synchronized 
after startup?

How many of such simple appliances can at all be configured to poll more 
than 1 server, poll all of them exactly at the same time, and then 
wonder why all servers return "UNSYNC"?

> On << The bits *announce* a leap second, but don't tell "the current timestamp is part of the inserted leap second".>>:
> Shouldn't the pair of (LI bits, UTC time stamp) be unique during a leap event? I mean: As long as the transmitted LI says that a leap event is going to happen (or is just happening), it did not happen yet, and once it did, LI should be "00" and the time should be correct. Where is the confusion?

As Warner Losh has recently explained, the problem here is the format of 
the POSIX timestamp that can't unambiguously encode the time before, 
during, or after a leap second.

All ntpd can do is pass a leap second warning to the OS kernel, and then 
monitor the kernel time status util it indicates that the kernel has 
handled the leap second, which way ever it has been done.

This ambiguity is exactly the reason why a server shoudl return "UNSYNC" 
for the 3 secioonds over the leap second, which is what ntpd does.

> Or if there is some, why not having (as I suggested) a leap indicator that is returned only when a leap second is currently in progress (that would be useful only to pure/dumb clients, and not to servers who need a "leap announcement from higher strati".

Pure, dumb clients probably won't evaluate this anyway.

As explained above, the problem is POSIX encoding and the missing status.

If you take e.g. a Meinberg PCI card and read the time from it using the 
public API calls, you consistently get a time stamp plus an associated 
status, which distinguishes between a leap second being announced and a 
leap second being in progress, so you can unambiguously convert this to 
human readavble time including second "60".

If the underlying OS doesn't support this, what could a program like 
ntpd (or ptpd) do?

> Finally on " That's why I say that it's sufficient and less confusing to only let
> servers send smeared time to clients, if smearing is required anyway.":
> Isn't that wishful thinking at least? That would require the servers and clients to be under the same administrative domain, right? For the Internet that would not work. And NTP is an Internet protocol, right?

Yes, and that's why public servers shouldn't smear. In the past, 
corporate admins decided that (and which of) their clients should get 
smeared time, and it worked really well.

A potential problem is when you used time.google.com, which smeared the 
leap seconds even in different ways at the last occurrences, and you 
didn't want and expect smeared time.

All the potential problems with smearing have been discussed many times 
in the past.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]
Phone: [phone]
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