Subject: [Ntp] Timescales

From: Hal Murray <[email-masked]>
Date: Wed, 09 Dec 2020 02:18:30 -0800

Crazy idea dept...  But maybe...

Can we make the basic time transfer protocol use a simple/clean time scale, 
say TAI with nothing in the basic protocol about leap seconds?

The idea is to push the leap second stuff to a sub-protocol or whereever.  
Keep the main protocol clean.  Let the client handle leap seconds.

("sub-protocol" doesn't seem like a good term, but I can't think of a better 
one right now.)

If you had such a split, would you package the extras as extensions or a 
separate mode?

Is there anything that would go in such a sub-protocol that involves "now"?  
For example, you might want to implement leap-smearing by saying "the offset 
from TAI is now xxxx" but you don't need that.  The client can compute the 
offset.

Aside from leap-second stuff, what else would get packaged that way?

------

Given TAI, there are 2 pieces of information that a clients needs to handle 
UTC and its leap seconds.  The first is the current TAI-UTC offset.  The 
second is when the next leap second happens.  That data changes very 
infrequently and with plenty of warning.  There is no need to clutter up 
on-the-wire protocols with it.  A client could get it from a leap-seconds file 
distributed by their distro.

-- 
These are my opinions.  I hate spam.

---

From: [email-masked]
Date: Wed, 9 Dec 2020 12:18:53 +0100

I've never understood how it came to be that this was considered the crazy idea and synchronizing to UTC where you have to deal with a system with irregular unpredictable leap seconds (that cause trouble in both on-wire protocols and implementations that actually discipline a device's clock) was considered the only possible sane solution.

Do we really have fewer problems now than we would if we had to deal with synchronization to TAI on one hand and managing TAI-UTC offset on the other hand? Because it does not seem so, and to me, using a jump-free/continuous timescale for on-wire parts of synchronization protocols seems like a no-brainer.

Best regards,

Kristof

-----"ntp" <[email-masked]> schrieb: -----

An: [email-masked]
Von: "Hal Murray"
Gesendet von: "ntp"
Datum: 09.12.2020 11:19
Kopie: "Hal Murray" <[email-masked]>
Betreff: [Ntp] Timescales

------

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 9 Dec 2020 12:30:03 +0100

> distributed by their distro.

Relying on a separate source like the leap-seconds file is not always
possible. The device may not have an up-to-date OS, or actually have
any writable memory to store that information.

There is definitely not a plenty of warning. Some reference clocks
give the leap announcement only an hour before it happens (e.g.
DCF77). Even delaying setting of the kernel leap status to the clock
update can be a problem if you are polling at 1024 seconds and have
more than two measurements dropped in a row in the clock filter.

-- 
Miroslav Lichvar

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 9 Dec 2020 14:06:50 +0100

Hal,

> say TAI with nothing in the basic protocol about leap seconds?

The most robust solutions is creating a time-scale that is some
well-defined shift from TAI, and then provide the TAI-UTC difference
explicitly along with a pre-warning system. Look at for instance GPS [1]
and PTP [2]. I've chosen this path myself and it has worked very nicely.

So, this is not a crazy idea, it's robust engineering proven in battle.

What is problematic is able to support backward compatibility to the
classical NTP time-scale as this needs to be handled in all time-stamps.

>From experience, you would *NOT* do it as an optional extension. It
would need to be a required extension, field and mechanism. The
flimsiness of optionality has been a major roadblock of getting this
properly rolled out. Even treating it as an extension creates issues
with processing and when the extension field is available. The hard
lesson learned is that the related field needs to be mandatory and
processing wise there more or less from the start.

So, while you technically move leap-seconds off the core time-stamps and
the time-scale those time-stamps is processed in, you should make sure
that the leap-seconds themselves remain part of the core protocol, with
very few corner case situations that can be well understood and well
managed.

> from TAI is now xxxx" but you don't need that.  The client can compute the 
You don't want to do smearing of leap-seconds, I see less and less use
for it. If you like, provide the parameters to convert hard TAI to UT1
if that suits the application better, but there can be multiple
applications on the same device that have different requirements, so all
such adaptations should be standardized and moved to the client side,
while core transport should have that know relationship to TAI, and
through that UTC, UT1 and various local times can be produced at client
side giving needed mapping information is there.
> Aside from leap-second stuff, what else would get packaged that way?
You can build a UT1 model parameters, consider how the corrections of
GPS time over to UTC is done in GPS [1].
> distributed by their distro.

No, that goes against the experience, and let me tell you it's bitter
experience. You need to transport it, and leapsecond file updates is
just a very big challenge to coordinate over a very diverse set of
machines while we have an increase need for proper TAI and UTC replicas
in clients. Remember that many uses of NTP is in wide range of
infrastructures with great challenges in updates, etc. Some is in very
locked down systems which may for all practical purposes be seen as
private networks having very little or no connection to Internet, or may
even be completely air-gaped. For such production environments even
getting an upgrade every 2 years can be challenging. Much of the issues
we have in other context is that machines do not get upgrades at all and
may be in excess of 5 years from last upgrade. While I try to fight to
have upgrades becoming natural for all systems, that fight will not be
over and done with in any reasonable time, so depending on it will be
moot. Some vendors tend to import code, but cripple configuration
freedom, and their upgrade rate is low to very low in the same type of
time-frame as system upgrades. Similarly will depending on detailed
configuration, we need to move away from source, intermediary node and
client configuration to be a major factor, as things is confusing and
not very helpful. The bringing the needed info over the protocol, albeit
out of the way for the core time-stamp processing, is what works and
what will survive.

Trying to rule out the transport of leap-second information from the bit
protocol is the crazy idea, it is just going to create more of the same
problems we face today, in fact, we could just put NTP into pension and
let PTP take over in that case.

So, to conclude my standing: Yes, you can move the core time mechanism
over to some variant of TAI, that is going to make core processing
easier and more robust, less corner cases in the core processing. No,
you can not move the leap-second information out of the core protocol,
in fact the opposite, you need to make it a mandatory field and
processing, but you can now let that remaining processing beyond
distribution become a client side issue as the core time over to
whatever the client need.

So, the crazy idea is in my mind thinking one can avoid the issue in the
core protocol, which will not be going well and already with the current
state of things can be a bit of a challenge. Just address the problem
proper once and for all, and learn from the good experience of other
systems.

Cheers,
Magnus

[1] IS-GPS-200L as available for free on gps.gov

[2] IEEE Std 1588-2019 as available for a cost on ieee.org

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 09 Dec 2020 14:22:33 +0100

>>> Hal Murray <[email-masked]> schrieb am 09.12.2020 um 11:18 in

> say TAI with nothing in the basic protocol about leap seconds?

Or two TAIs and two offsets?:
(TAI and current offset from UTC) (time of next offset change as TAI, next
offset)

I think the main challenge is how to represent required and optional data
items.
Once you have this pick the rest like pizza topping ;-)

> 
> The idea is to push the leap second stuff to a sub‑protocol or whereever.  
> ("sub‑protocol" doesn't seem like a good term, but I can't think of a better

> Is there anything that would go in such a sub‑protocol that involves "now"? 

> For example, you might want to implement leap‑smearing by saying "the offset

> Aside from leap‑second stuff, what else would get packaged that way?
> 
> ‑‑‑‑‑‑
> 

> UTC and its leap seconds.  The first is the current TAI‑UTC offset.  The 
> on‑the‑wire protocols with it.  A client could get it from a leap‑seconds
file 
> ‑‑

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 09 Dec 2020 14:29:32 +0100

>>> Miroslav Lichvar <[email-masked]> schrieb am 09.12.2020 um 12:30 in
Nachricht <20201209113003.GA2352378@localhost>:
> On Wed, Dec 09, 2020 at 02:18:30AM ‑0800, Hal Murray wrote:

file 
> Relying on a separate source like the leap‑seconds file is not always
> possible. The device may not have an up‑to‑date OS, or actually have

However you could see the leap indication flag also as "leap confirmation"
flag (actually there will be a leap event). With only DCF-77 clocks this could
be a problem. As said earlier, it would be best if NTP could reliably transfer
the leapsecond table, or at least the relevant part of it to make clients know
in advance that and when a leap event is scheduled.

Regards,
Ulrich

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 9 Dec 2020 14:44:53 +0100

Ulrich,

> in advance that and when a leap event is scheduled.

A mechanism that works well conveys the current value, when an upcoming
event is occurring and which direction it will be. That solves most of
the practical problems. For back-dating purposes, which is more of an
obscure corner-case, being able to also provide older parts of the
leap-second history is nice, but rarely very useful.

A less useful but still helpful mechanism is when there is a pre-warning
mechanism of upcoming event and indication when the event occurs. For
this to fully function the current value needs to be supplied from the
side, but from then the updates can be done correct if the node is
operational during the pre-warning interval. The strength in providing
the current value directly is that you instantly can be "on the right
page, eh second" and the strength of the pre-warning system is that you
in advance can know of the leap second. In GPS for instance, you have in
practice over 5 months of pre-warning, and you get an indication of when
the event will occur so you can even be non-operational during the event
and as you wake up instantly provide the correct value even if the
current value update can be slugish (12.5 min cycle for transmission).

So, a good and simple mechanism is to give the current TAI-UTC offset,
then have a flag indicating up-coming leap-second event, give the
system-timestamp for when this event occurs and the TAI-UTC offset as
result of that leap-second insertion.

Piggybacking a historic leapsecond file transfer will always be a nice
feature, but not strictly required if this is in place.

Cheers,
Magnus

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 9 Dec 2020 14:46:12 +0100

> in advance that and when a leap event is scheduled.

There is the tzdist (RFC7808) protocol designed for that.

NTP could distribute a leap-second table (it already did it with
Autokey, right?), but isn't NTP about distributing current time,
rather than reconstructing time in the past or future?

-- 
Miroslav Lichvar

---

From: FUSTE Emmanuel <[email-masked]>
Date: Wed, 9 Dec 2020 14:02:22 +0000

> proper once and for all, and learn from the good experience of other
So what do you think about this ?
What we need is some new NTP messages for leap / Time-scale 
conversion/correction tables "like" the GPS almanach and navigation tables.
A client could then built/rebuild/update local tables by chunk by doing 
a request with his serial/timestamp of it known data without external 
intervention and at a rate different from the NTP measuring messages.
It could be done securely with data signing and in band signing key 
rollover.
It is quite challenging and a lot of work for v5 but could be defined as 
an NTPv5 extension and core part of future v6.
For v5 without extension, we rely on out of band update of the data as 
"critical" systems do today anyways for the leap.
But it is perhaps too radical.

Emmanuel.

---

From: FUSTE Emmanuel <[email-masked]>
Date: Wed, 9 Dec 2020 14:07:28 +0000

> rather than reconstructing time in the past or future?
"Current" is a referential problem. As soon as you distribute/tackle 
different time scale which one is "current" ?
You will more or less  inevitably start to need to reconstruct time in 
the past or future.

Emmanuel.

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 9 Dec 2020 15:22:05 +0100

> You will more or less  inevitably start to need to reconstruct time in 

In all timescales there should be a value corresponding to current
time. It may be ambiguous.

For the purposes of clock synchronization I think the client just
needs to know the current time and whether there will be a leap second
in the next slot if the timescale jumps on the leap second. If NTP
should also allow the client to know current time in another
timescale, it also needs to know the current offset (e.g. relative to
the receive timestamp) between those two timescales. The NTPv5 draft
does that.

Most computers work primarily in UTC. The leap second tables are not
universally available. NTP needs to keep the UTC support and work even
when the TAI-UTC offset is unknown.

-- 
Miroslav Lichvar

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 9 Dec 2020 15:48:19 +0100

Emmanuel,

> But it is perhaps too radical.

Already in NTPv4 there is a mechanism as documented in RFC 5906
sub-clause 10.6 and some scattered comments around. As a minimum level
we should retain that after liberating it from the Autokey context. It
has the draw-back of depending on the leap-second history, as typical
with NTP time-stamps.

I see no reason to wait another major revision for it, if you choose
methods, it's fairly straight-forward and not a lot of code, the needed
corner cases can be described and well understood. What you propose is
to take a step back, not a step forward.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 9 Dec 2020 15:59:18 +0100

Emmanuel,

> You will more or less  inevitably start to need to reconstruct time in 

Not necessarily. In fact we constantly bound time around in time-scales
whose epochs is defined in "dark ages" but we have built relationships
that is true from some recent enough time that we know how the
time-scales relate. You can however make decisions in your
implementations which force you to bring the full history, where as you
can avoid that with other technological decisions. For example, in the
GPS system, the satellites transmit time in the internal GPS time-scale.
There is a lot of correction factors, but applying those according to
the given values in the signal and given math, all detailed in
IS-GPS-200L, you derive the compensated replica of the GPS time-scale.
Then, by applying corrections this can then be shifted over to become an
UTC replica time-scale in the receiver. The current time in GPS-time or
UTC-time is available fairly quickly after lockup, and all the data is
given either a priori in the IS-GPS-200L or in the signal as described
in IS-GPS-200L. So yes, except for some uncalibrated biases you have the
current time there, fairly stable and fairly accurate considering just
how little hardware cost, require in setup and everything.

The way that NTP time-scale "shifts" with each leap-second is a protocol
design issue which causes NTP to need the history to know the
relationships and when they apply, but just giving the last correction
and eventually the future correction you are all set again.

It's the trying to avoid carrying the differences in the signal which is
causing more problems than it solves.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 9 Dec 2020 16:11:32 +0100

Miroslav,

On 2020-12-09 15:22, Miroslav Lichvar wrote:
>> Le 09/12/2020 Ã  14:46, Miroslav Lichvar a Ã©critÂ :
>> You will more or lessÂ  inevitably start to need to reconstruct time in 
>> the past or future.
While I in general agree with you, a few words.

First of all, we never get the "real" UTC, but only a local replica
attempting to follow and respect some other time-scale, may it be UTC or
TAI or whatever. Depending on how well we do the job in the chain from
the source to the client, this replica may be more or less well aligned
to the time-scale it attempts to replicate.

It turns out that we have an increasing need to create TAI or PTP local
replicas in addition to UTC replicas, and yes this is implied even with
NTP as timing protocol. In the media industry we move all of our
processing over to that, while we do more and more on "normal" clients.
In fact, many other processing things occurs on essentially Linux
platform for a whole range of processing needs. So, the need to know the
TAI-UTC leap-second offset in addition to current time is needed.

In my mind, the train to discuss the need for leap-second information
has already gone. Too many applications start to need it for them to
function well, and if NTPv5 is not able to deliver that, then it should
either be redesigned to just dropped as an effort and focus on a
revision of NTP that does support it, because what is needed is a
solution that supports this. In the meanwhile, PTP has the needed
support and we could just drop NTP and go all PTP then. Personally I
think there is great value in NTP for many applications, if only it can
handle this properly along getting secure with NTS.

Cheers,
Magnus

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 9 Dec 2020 16:21:25 +0100

> handle this properly along getting secure with NTS.

I don't understand everything you said, but I think we are in
agreement. My draft supports both UTC and TAI. It also provides the
TAI-UTC offset when known.

That's similar to PTP. It can work in TAI or the "arbitrary"
timescale, typically UTC. There is a field for the TAI-UTC offset and
there is a flag to indicate it is valid.

-- 
Miroslav Lichvar

---

From: Steve Allen <[email-masked]>
Date: Wed, 9 Dec 2020 08:29:23 -0800

> classical NTP time-scale as this needs to be handled in all time-stamps.

The extended discussion in the NTPWG now is strikingly similar to the
arguments in the late 1960s which resulted in leap seconds.
A 1969 report analyzing the options pointed out that leap seconds
would cause problems in precise timing systems used for navigation.
Backward compatibility concerns forced the international agreement to
have leap seconds.  Before the first leap second the technical members
of the committees proceeded to change their operational systems to use
purely atomic time with no leaps, and that choice was repeated for
GPS, Galileo, BeiDou, etc. because it was the only robust way.

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m

---

From: Hal Murray <[email-masked]>
Date: Wed, 09 Dec 2020 11:02:10 -0800

[email-masked] said:
> Most computers work primarily in UTC.

Most computers work on POSIX pseudo UTC time.
(which is why we have this leap-second mess)

---

From: Warner Losh <[email-masked]>
Date: Wed, 9 Dec 2020 12:49:31 -0700

> handle this properly along getting secure with NTS.

One of the biggest issues I had with getting leap seconds to work right is
distribution. NTP v4 punting leapseconds to some crazy autokey ghetto
didn't help. Leap seconds are always some bastard stepchild in the timing
community. Yet they are also critical for UTC to be implemented correctly.
You can't purport to be a UTC time scale w/o distributing at least some
portion of the leap second table. If NTP can't make leap seconds first
class citizens that are mandatory for all implementations to  implement,
then they will continue to be bastard step children.

Most reference clocks will provide this information at stratum 1. Some will
not and we should shift the burden of those clocks to require
administrative support. They are rare and the main protocol shouldn't be
designed to cater to recovery of phase and frequency without meaningful
recovery of the meta-data that UTC needs to be implemented correctly...

Warner

---

From: Warner Losh <[email-masked]>
Date: Wed, 9 Dec 2020 12:50:51 -0700

> (which is why we have this leap-second mess)

Yes. Most applications want UTC because it's close enough to legal time.
Most programmers approximate it with POSIX time which is close enough most
of the time and that odd second every 18 months doesn't matter enough to
retool.

Warner

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 9 Dec 2020 23:11:27 +0100

Miroslav,

> there is a flag to indicate it is valid.

I will make sure to check the details of the latest draft, I've not had
the time to quality check everything with that in mind, my comments have
mainly been reactions to other peoples posting on the list. Feel free to
bang my head if you don't get any feedback from me within the week.

There is one particular notion that I want to make sure is captured, in
that the TAI-UTC leap second difference should be available such that
unambigous interpretation into TAI, UTC, UNIX/POSIX, LINUX time-scales
can be provided as the norm.

Cheers,
Magnus

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 9 Dec 2020 23:14:42 +0100

Warner Losh wrote:
> One of the biggest issues I had with getting leap seconds to work right
> is distribution.

I think we should differ here between pure leap second warnings and the
UTC offset.

IMO, NTP's concept to distribute *leap second warnings* is fine, as long
as the information is early enough available to the stratum-1 servers.

This is totally sufficient for systems that just work on UTC/POSIX time
or the local time zones derived from these, and I'm pretty sure there
was no requirement to distribute TAI when NTP was invented.

> NTP v4 punting leapseconds to some crazy autokey ghetto
> didn't help.

Distribution of the TAI/UTC offset is another topic. You need it only if
you have some systems that work with TAI.

In retrospect, distributing the full leap second table via Autokey looks
like a hack to add a feature that was originally missing. Now, where
Autokey is deprecated, there should be a new, proper way to distribute
the TAI offset, be it via an extension field for NTPv4, a mandatory
field for NTPv5, or even a companion protocol like tzdist.

Unless you need to work with historical data, you even don't need to
distribute the full leap second table. The current offset is sufficient,
and together with the leap second warning the offset can be properly
maintained across a leap second (well, except for the limitation of
POSIX time, on which NTP depends).

As I said before, in any case you need to work with a TAI time scale you
need a proper source for that information, and as I also mentione
before, not every time source that can provide UTC and leap second
warnings can be used to provide the UTC/TAI offset. See DCF77, for example.

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: Wed, 9 Dec 2020 23:40:20 +0100

> GPS, Galileo, BeiDou, etc. because it was the only robust way.

True, and I agree, but if you need civil time, corrections and offsets
also have to be provided by these systems.

Of course, the operators of the GNSS systems provide this information
via the satellite signals, but if you operate your own NTP stratum-1
server (or your own PTP grandmaster) you have to find a reliable source
for this kind of information. If this is a leap second file, you have to
make sure the file is always kept up to date.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 9 Dec 2020 23:40:32 +0100

Hal,

> (which is why we have this leap-second mess)

Most computers use one of two interpretations of POSIX Time.

One variant of UTC to POSIX time_t mapping was provided for a while, but
later removed from the POSIX documentation, mapping 23:59:60Z into
00:00:00, which is what you expect from (omitting date)

time_t = hours*3600 + min*60 + sec

and as this is re-interpreted as print-out time

sec = time_t % 60
min = (time_t / 60) % 60
hour = (time_t / 3600) % 24

reads out as 00:00:00, which next section also labelled 00:00:00. This
behavior is mimiced by the NTP time-scale for at NTPv3 and NTPv4 as I
recall it.

Then, for Linux the leap-second is not assigned the printed label
00:00:00 but the printed label 23:59:59, which keeps 00:00:00 unique to
the first second of the new UTC day. Thus, rather than double 00:00:00
read-outs you have double 23:59:59 read-outs. Thus, we cannot speak
about them both having UNIX or POSIX time as if it was the same, but
they are different and we need to treat them different. NTP
implementations needs to know how to handle it, and in practice it is
handled through the nanokernel interface [1]. The user applications
should use that interface too, to get the offset, but some operating
systems also support getting time in the TAI form, see CLOCK_TAI for
clock_gettime() [2].

While my manual references is to Linux, the BSD guys for sure can
illustrate the state there.

But, the lesson is that even within "UNIX type systems" you have a
diversity, but there may also be the common enough tool-set to help
applications to get time straight if we only enable the NTP process to
use the right interfaces and allow the protocol to transport all the
needed information.

I think some of the discussions of issues relates to older ways to get
time-stamps, which may no longer reflect the state of art available on a
wide selection of systems. The inclusion of these new interface is now
quite old, so it has rippled through the builds and support through
various libraries etc.

Cheers,
Magnus

[1] https://man7.org/linux/man-pages/man3/ntp_adjtime.3.html

[2] https://man7.org/linux/man-pages/man2/clock_gettime.2.html

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 9 Dec 2020 23:47:21 +0100

> when the TAI-UTC offset is unknown.

I fully agree.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 9 Dec 2020 23:53:08 +0100

> rather than reconstructing time in the past or future?

As I said earlier, IMO the current TAI offset would be sufficient.

BTW, do you know Poul-Henning Kamp's Proposal to distribute leap second
warning and the current TAI offset via DNS? See:
http://phk.freebsd.dk/time/20151122/

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 10 Dec 2020 00:02:21 +0100

[email-masked] wrote:
> I've never understood how it came to be that this was considered the
> crazy idea and synchronizing to UTC where you have to deal with a system
> with irregular unpredictable leap seconds (that cause trouble in both
> on-wire protocols and implementations that actually discipline a
> device's clock) was considered the only possible sane solution. 

If you keep in mind what was available before NTP was introduced ...

The original IBM PC didn't even provide a batter buffered RTC chip, and
you had to enter the current date and (local) time whenever the (DOS-)
system booted.

As I've mentioned earlier, I think the rotocol is fine as long as you
only need UTC, and leap second warnings can be properly propagated. The
problem is what *operating systems* do to handle a leap second, and
applications suffer from the way the operating system do it.

> Do we really have fewer problems now than we would if we had to deal
> with synchronization to TAI on one hand and managing TAI-UTC offset on
> the other hand? Because it does not seem so, and to me, using a
> jump-free/continuous timescale for on-wire parts of synchronization
> protocols seems like a no-brainer.

If you use TAI, at some point the TAI offset has to be fed into the time
synchronization chain, and some maintenance is required to do this
reliably over time.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 10 Dec 2020 00:10:14 +0100

> behavior is mimiced by the NTP time-scale for at NTPv3 and NTPv4 as I

The problem is that there is no status flag. For example, if you read a
POSIX-like timestamp from a Meinberg PCI card, there are API calls that
also include a status word, and while one of the status bits tells that
a leap second is approaching, another bit tells that the current second
is a leap second, so you can properly solve the ambiguity if you
evaluate the status flag.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Hal Murray <[email-masked]>
Date: Wed, 09 Dec 2020 15:12:53 -0800

[email-masked] said:
> There is one particular notion that I want to make sure is captured, in that
> the TAI-UTC leap second difference should be available such that unambigous
> interpretation into TAI, UTC, UNIX/POSIX, LINUX time-scales can be provided
> as the norm. 

That introduces an interesting tangle.  The raw data for when the next leap 
second happens is something like the "end of next December".  If we use that 
approach, it only takes 3 bits to describe when the next leap second will 
happen: 6 states for the next 6 months and 2 more states for none, and 
I-don't-know.  That drags in a calendar package.  (Yes, you need another bit 
somewhere for insert/delete the leap.)

I think the API to most kernels is leap-tonight.  That leaves the day/month 
logic outside the kernel.  I haven't poked around to see how "tonight" gets 
converted into a second.  Probably by dividing by 86400.

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 10 Dec 2020 00:24:58 +0100

Warner,

On 2020-12-09 20:49, Warner Losh wrote:
>
>
> On Wed, Dec 9, 2020 at 8:11 AM Magnus Danielson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Miroslav,
>
> One of the biggest issues I had with getting leap seconds to work
> right is distribution. NTP v4 punting leapseconds to some crazy
> autokey ghetto didn't help.
Agree. We implemented (really used enabled it's use) autokey only to get
the leapsecond difference.
> Leap seconds are always some bastard stepchild in the timing community.

Disagree. There is several designs that handles it really well, that
have taken it really serious and you just said their work was bad, as
they are too in the timing community. It wasn't bad work, it was wrong
identification of the community.

> Yet they are also critical for UTC to be implemented correctly. You
> can't purport to be a UTC time scale w/o distributing at least some
> portion of the leap second table.

Please note that the leap second file is a NTP centric term, defined to
meet NTP specific needs as NTP was designed before. We may need to
unlearn that when we speak about time in general. The list of historic
IERS leap-second decisions is distinct from the leap second file.

What is true is that we need to know the current TAI-UTC difference, and
when a decision for an upcoming change comes, we also needs to
distribute this knowledge in advance to the event occurring, and then
when that is going to occur and the new TAI-UTC difference from that point.

If we can provide a historic list, that's fine. I prefer to identify TAI
time (directly or indirectly as suitable) at which a leap-second occurs
and the new TAI-UTC time at that point. Turns out to make interpretation
cleaner, much cleaner. This works well in GPS for instance, and even GPS
added it as an after-thought to the original signal structure.

> If NTP can't make leap seconds first class citizens that are
> mandatory for all implementations to  implement, then they will
> continue to be bastard step children.
Yes, and it will make NTP harder and harder to use for many applications.
>
> Most reference clocks will provide this information at stratum 1. Some
> will not and we should shift the burden of those clocks to require
> administrative support. They are rare and the main protocol shouldn't
> be designed to cater to recovery of phase and frequency without
> meaningful recovery of the meta-data that UTC needs to be implemented
> correctly...

Agree.

We can actually allow for a more flexible view, but tolerating the range
will become somewhat of a challenge.

We can have:

0) Djungle-clock, frequency, phase, time and full TAI-UTC difference
unknown/uninitiated.

1) Proper SI-second frequency, but phase, time and full TAI-UTC
difference unknown/uninitiated.

2) Proper SI-second frequency and phase (with some bound of phase
errors, which may be unknown but reasonably stable), but time and full
TAI-UTC difference unknown/uninitiated.

3) Proper SI-second frequency, phase and time-scale time, but unknown
TAI-UTC difference.

4) Proper SI-second frequency, phase, time-scale time and TAI-UTC
difference.

For each step, we gain additional knowledge and corrections. Notice that
I have avoided telling exactly which time-scale is being used, as that
ends up being less relevant for the overall scenario, while the
technical details of course matters grately, but you end up loosing
track of the bigger picture.

Notice that none of these provide any real accuracy and uncertainties in
the actual product, any form of meterology traceability aspects can not
be assumed by this, as I intentionally left out all those calibration
and traceability issues, they come as a separate discussion.

As you "fall back" one step, some specific thing drops out. However,
even stage 1 can be useful as it will provide the right frequency for
hold-over even if phase, time and TAI-UTC offset can not be updated.
Allowing for a source to step among these and do the best with the
situation will for sure provide the best approach for robustness. We
could even make independent decisions about our trust level for each of
the information given.

So, what we for the moment haggle about is really if we can assume NTP
to be a stage 3 or stage 4 type of service as default. I am advocating
that we shall make sure that the default behavior of future NTP devices
aim to achieve stage 4 level with minimum of configuration for
intermediary and client nodes. We end up needing that TAI and UTC sense
for so much these days. I also think it should not be too hard to design
things to achieve that, and there is plenty of good examples to
illustrate that, so lets learn from that and incorporate as we go forward.

Historically there have been gazillions of small little reasons making
the road unnecessarily rocky, and many of these technical reasons really
come from not having the ambition to make the design should achieve
stage 4. Rather than dwelling too much in the history, we should focus
on what we want to achieve in the future, and see what needs we see in
diverse set of applications. Just from my day-job I can tell you that I
seeing more and more need for stage 4 level of support and I feel sad
that trying to do it with NTPv4 make so many cuts and bruces. For other
mechanisms that is much less so an issue and I've designed my own system
for our products and not found it too hard to do proper in those
designs, if you only choose to have the mindset, which is maybe we this
ends up being the problem.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 10 Dec 2020 01:23:39 +0100

Martin,

> evaluate the status flag.

Agreed. This is why I think one should look at other interfaces to get
the time, such that sufficient information is available. If you use
ntp_gettime() for instance you get considerable more meta-data. Also,
you can get time-stamps in CLOCK_TAI for instance for some OSes.

In general, I think we should make people aware of such solutions, make
sure they functions and promote their proliferation.

Cheers,
Magnus

---

From: Philip Prindeville <[email-masked]>
Date: Wed, 9 Dec 2020 17:33:08 -0700

> On Dec 9, 2020, at 9:29 AM, Steve Allen <[email-masked]> wrote:
> 

Maybe I’m just slow, but I’m not getting any of this discussion.

It seems to me that time advances, only, and at a fairly constant rate (barring relativistic shifts as the earth accelerates as it moves in the same direction as the sun’s trajectory, vs. decelerating when the earth’s orbit takes it in the opposite order as the sun’s trajectory, etc.).

It simply goes “tick tock tick tock”… and that’s all it does.

Anything relating to mapping to dates and times on a calendar is a purely “presentational” thing, like preferring decimal over octal or hex or binary…

It seems to me we’re overthinking things.

Or worse, assuming we’re the only ones that really understand time, and deciding “we” should fix it “here” because we understand it, rather than letting “them” fix it “there” because we don’t trust others to do so adequately.

What am I missing?

-Philip

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 10 Dec 2020 02:11:09 +0100

Philip,

> Or worse, assuming we’re the only ones that really understand time, and deciding “we” should fix it “here” because we understand it, rather than letting “them” fix it “there” because we don’t trust…

Through history we kept inventing ways to describe and annotate the
time. Not all of them have their annotations increase monotonically for
a myriad of reasons. Trying to get some order in this quaggmire tends to
be "interesting" depending on how much each person learned and through
their exposure to various solutions, and also lack of exposure to
various solutions. With that comes both benefits and problems. As time
passes, new things is added, new quick-hacks is added, more labyrinth of
details show up and requirements shift over time.

Keeping a common map can be challenging, especially as one has to be
detailed on details and for what case they apply and not.

Whatever simplification one come up with, it ends up causing things to
be painful somewhere else. Getting the set of good guys here agree takes
a bit of talking.

Cheers,
Magnus

---

From: Steve Allen <[email-masked]>
Date: Wed, 9 Dec 2020 17:28:00 -0800

On Wed 2020-12-09T17:33:08-0700 Philip Prindeville hath writ:
> It seems to me that time advances, only, and at a fairly constant rate [...]
>

Time does that and clocks do not.

In the arena of precise time a few basic principles that do not exist
in POSIX time are

All sources of time disagree; all clocks are wrong.
Political/legal/bureaucratic concerns of agencies funding maintenance
and distribution of time sometimes overrule technical concerns.
Systems wanting precise time need a plan for dealing with all that.

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 10 Dec 2020 07:55:59 +0100

>>> Magnus Danielson <[email-masked]> schrieb am 09.12.2020 um 14:44 in
> feature, but not strictly required if this is in place.

Hi!

That's why I wrote "or at least the relevant part of it", meaning whether
there will be a leap event withing the next six months or not. That's deinitely
not a lot of data. The only reason to send the full table would be having to
avoid parsing the table before sending.

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 10 Dec 2020 07:59:41 +0100

>>> Miroslav Lichvar <[email-masked]> schrieb am 09.12.2020 um 14:46 in
Nachricht <20201209134612.GC2352378@localhost>:
>> flag (actually there will be a leap event). With only DCF‑77 clocks this 
> could
> NTP could distribute a leap‑second table (it already did it with

Hi!

You all seem to have missed my point: In the recent past there was a lot of
discussion and confusion what the LI (Leap Indicator) means:
Leap second today, leap second at the end of the month, leap second soon. So
having the definite time of the next leap event would all make this easier.
Actually it could make the LI even obsolete.

Regards,
Ulrich

---

From: Warner Losh <[email-masked]>
Date: Thu, 10 Dec 2020 00:27:13 -0700

On Wed, Dec 9, 2020, 11:56 PM Ulrich Windl <
[email-masked]> wrote:

> >> flag (actually there will be a leap event). With only DCF-77 clocks
> this
> > could
> >> the leapsecond table, or at least the relevant part of it to make
> clients
> > know

Technically, a leap second can happen at the end of any month. It would be
foolish to bake the 6 month thing in. Even so, the entire leap second table
can be encoded in less than 100 bits today. Less if you get a bit clever
with compression.

I do agree that you can compress the relevant bit to 1 in the steady state
once you know. But for discontinuous operation you need more to fully
implement UTC, including correct reckoning of elapsed time between two
events. Declaring these sorts of problems as outside the scope is why I
make comments like bastard step child. Or put another way: if they were
properly implemented, we'd have no need for smearing...

Exchanging the metadata about UTC (or whatever timescale) is needed to
completely implement it. Time exchange needs to be thought of as more than
just a phase delta measurement.

Warner

Regards,

---

From: Steve Allen <[email-masked]>
Date: Thu, 10 Dec 2020 06:36:50 -0800

> Actually it could make the LI even obsolete.

There is an obscure historical warning that NTP should keep in
consideration about upcoming leap seconds.  The text of ITU-R TF.460
still says

    A positive or negative leap-second should be the last second of a
    UTC month, but first preference should be given to the end of
    December and June, and second preference to the end of March and
    September.

The reason that no date other than December and June has been used
originated in a gentleman's agreement between one member of the CCIR,
one member of the CIPM, and one representative of the Soviet Union.
All of those people and two of those agencies no longer exist.  The
people in the agencies that currently administer UTC may not be
bound by that agreement.

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 10 Dec 2020 15:52:56 +0100

Ulrich,

Ulrich Windl wrote:
> Leap second today, leap second at the end of the month, leap second soon.

Hm, I don't remember this kind of discussions.

For NTP the LI always means that the leap second is scheduled for the
end of the current month.

What can be discussed is, how much time in advance a leap second can or
should be announced.

IIRC, for the Linux (Unix?) kernels, setting a leap indicator indicates
that a leap second is scheduled for the end of the current day. For the
kernel it would be basically sufficient if the announcement arrives a
few seconds before the leap second occurs, so this is fine and flexible.

For NTP, PTP, etc. this is usually too short because the announcement
may have to be passed down a whole synchronization chain with large
polling intervals. So you have to start the announcement earlier than
for the kernel. 24 hours is a good interval, but up to 1 month would be
possible if you can take into account that future leap seconds might
occur at the end of any month.

If I remember correctly, PTP even has a specification for specifies 12
hours in advance.

> So

Yes. This is what the GPS nav message does, but we've seen that this
isn't sufficient if the implementors don't work carefully, and wrong
announcements are emitted.

This is why programs like ntpd try to do more or less plausibility
checks to avoid this, but you have seen here on the list that there are
even complaints if those plausibility checks fail because you can't
avoid every potential bug from upstream.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 10 Dec 2020 20:07:50 +0100

Ulrich,

> Actually it could make the LI even obsolete.

No, not really. I did see that, but there is a subtle point to it.

You have two scenarios:

1) You know the current TAI-UTC offset, and there is no know upcoming
offset.

2) You know the current TAI-UTC offset, and you know there is a upcoming
new offset introduced at Time T to become offset O.

As you provide the T and O values, you need to know if those fields is
valid or not, for that you typically use a separate flag to indicate
that, rather than put restrictions on how to interpret those values to
mean that. So, I think it is provides a much better function to have
such a flag.

Separate from that, people have suggested that a flag should indicate a
particular occurrences time. Unfortunately, that has proven the source
of nasty bugs, and also, it can put implications of for how long before
it can be announced, and you end up knowing that you know there is an
upcoming leap second, but the distribution mechanism does not allow you
to announce it yet because it would be interpreted for the wrong time.
Whenever possible, it is therefore advisable to always supply the
time-stamp at which time the future event will occur, as it then leaves
no room for misinterpretation. In the similar sense, it is advisable to
not use interpretation of the fields to know if they provide a future
event or not, but only indicate the facts about the future event which
occurrence is flagged with a dedicated bit.

Being able to compress things does not make it wise, in fact it has
turned out to be very unwise to do so, as it is not future-proof at all.

So, this is why I advocate for a flag to indicate upcoming leap-second,
a field to indicate the current TAI-UTC difference, upon the flag being
set the values of future time-stamp and new TAI-UTC offset becomes valid
fields.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 10 Dec 2020 20:20:07 +0100

Warner,

On 2020-12-10 08:27, Warner Losh wrote:
>
>
> On Wed, Dec 9, 2020, 11:56 PM Ulrich Windl
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     >>> Magnus Danielson <[email-masked]
>     <mailto:[email-masked]>> schrieb am 09.12.2020 um 14:44 in
>     Nachricht <[email-masked]
>     <mailto:[email-masked]>>:
>     > Ulrich,
>     >
>     >> flag (actually there will be a leap event). With only DCF-77
>     clocks this
>     > could
>     >> be a problem. As said earlier, it would be best if NTP could
>     reliably
>     > transfer
>     >> the leapsecond table, or at least the relevant part of it to
>     make clients
>     > know
> Technically, a leap second can happen at the end of any month. It
> would be foolish to bake the 6 month thing in. Even so, the entire
> leap second table can be encoded in less than 100 bits today. Less if
> you get a bit clever with compression.
>
> I do agree that you can compress the relevant bit to 1 in the steady
> state once you know. But for discontinuous operation you need more to
> fully implement UTC, including correct reckoning of elapsed time
> between two events. Declaring these sorts of problems as outside the
> scope is why I make comments like bastard step child. Or put another
> way: if they were properly implemented, we'd have no need for smearing...
>
To extend your discussion with an example when it fails:

In the HP Z3801A GPSDO clock, the Motorola GPS OEM module flips a flag
to indicate that there is an upcoming leap-second. You can read out of
the OEM module when the leap-second occurs. However, the firmware choose
to interpret this to be in the last month of the UTC quarter, which is
secondary choice position in the ITU-R specification of time
transmissions. Now, as IERS chooses to only use the primary choice
position, that is end of june and end of december, and IERS publish
their decision just a few days after half-year, and the fact that the US
Air Force operation of the GPS constellation chooses to insert the
upcoming leap second typically within a few weeks of the IERS
annuncement, this means that the indication flag for leap second occurs
in two quarters, so the Z3801A will insert it in the wrong quarter. This
despite the availability of the correct time-stamp, which is a pure
software bug.

This is a great example how you should not interpret the flag value to
have implied time-meaning. You have two sets of specification, two
controlling organizations, two different vendors of equipment integrated
together. There is good chance things gets done the wrong way.

> completely implement it. Time exchange needs to be thought of as more
> than just a phase delta measurement.

Agreed. We learned this from bitter experience. We have seen severe
problems and we had to completely decommission equipment from operations
because of it.

Just do a very strict and clear design. It still cost a few bits, but it
ends up producing more transparent and robust mechanisms, that can be
adapted to the changing situation.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 10 Dec 2020 20:44:32 +0100

Steve,

> people in the agencies that currently administer UTC may not be

However, they do respect the preference given in the above paragraph, so
it remains effectively still in action.

There is however nothing which prohibits other decisions would IERS
decide they need to.

Also note that in NTP lingo, since the NTP time-scale have been defined
the way it has, the leap-second occurs in the NTP first second of month,
with first preference of January and July. That for sure help to confuse
the issue.

Cheers,
Magnus

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 11 Dec 2020 08:38:12 +0100

>>> Magnus Danielson <[email-masked]> schrieb am 10.12.2020 um 20:07 in

>>>> the leapsecond table, or at least the relevant part of it to make clients

So
> valid or not, for that you typically use a separate flag to indicate

Actually no: if the T is in the past it's equivalent to "no leap event
scheduled" (and vice versa).

> set the values of future time-stamp and new TAI-UTC offset becomes valid

The only disadvantage I see is that T seeds some extra bytes.

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 11 Dec 2020 08:41:41 +0100

>>> Magnus Danielson <[email-masked]> schrieb am 10.12.2020 um 20:20 in
Nachricht <[email-masked]>:
...

> Just do a very strict and clear design. It still cost a few bits, but it
...

+1 ;-)

---

From: Magnus Danielson <[email-masked]>
Date: Fri, 11 Dec 2020 17:03:51 +0100

Ulrich,

>> mean that. So, I think it is provides a much better function to have
Do read the complete sentence. There is many ways to have values "flag"
things. Each such ends up being problematic in the long run.
> The only disadvantage I see is that T seeds some extra bytes.

Which is a relatively light weight price to pay for a robust mechanism
these days.

You can check the size of the fields for GPS in IS-GPS-200L. That is
carried over a 50 baud data-channel, and while only allowed to transmit
every 12,5 min, it have provided a robust mechanism since it's introduction.

Cheers,
Magnus