Subject: [Ntp] Resending: Thoughts on draft-ietf-ntp-refid-updates

From: Philip Prindeville <[email-masked]>
Date: Wed, 18 Jul 2018 10:34:03 -0400

Might as well send to the entire WG.

> Begin forwarded message:
> 
> From: Philip Prindeville <[email-masked]>
> Subject: Thoughts on draft-ietf-ntp-refid-updates
> Date: July 18, 2018 at 9:06:17 AM GMT-4
> To: [email-masked]
> Cc: [email-masked]
> Resent-From: Philip Prindeville <[email-masked]>
> Resent-To: Harlan Stenn <[email-masked]>
> Resent-Cc: Steve Sullivan <[email-masked]>
> 
> I just reread: https://datatracker.ietf.org/doc/html/draft-ietf-ntp-refid-updates and I don’t see the point of leapsmear.  Accurate time is accurate time.  Broken clients are a separate problem.  The best we can do is provide accurate time to them.  If they don’t know what to do with that, that’s their problem, not ours.
> 
> I say with nix leapsmear.
> 
> * * *
> 
> Rather than leaking address information via the REFID field, what about making REFIDs (a) be a hash sufficiently long (say 160 or 256) and (b) making the REFID’s be unique to pair-wise communication, i.e. making them only be relevant to the pair of hosts communicating?
> 
> Host a could advertise nonce_a, and then send a ref-id to b of {nonce_a, hash(nonce_a || address_a || address_b)}.  b would then be able to recompute hash(nonce_a || address_a || address_b) and detect a timing-loop.  nonce_a would be unique for all associations, and hence a malicious third party wouldn’t known nonce_a expect by doing a MITM attack and eavesdropping (or replacing the hashes and nonces).
> 
> For multicast or subnet broadcast mode, address_b would be that address… and hence potentially guessable by an adversary, but most perimeter gateways (firewalls) should be blocking multicast and directed-subnet broadcasts anyway.
> 
> Then we don’t need the NOT-YOU REFID because leaking REFIDs aren’t linkable anyway.
> 
> * * *
> 
> Regarding Section 3.3, I’d put all zeros in the REFID, and mean this to mean “find the REAL REFID” in an an extension field.
> 
> * * *
> 
> I don’t like the idea of REFIDs being overloaded for leap smearing.
> 
> * * *
> 
> -Philip
> 
> Begin forwarded message:
> 
> From: Philip Prindeville <[email-masked]>
> Subject: Thoughts on draft-ietf-ntp-refid-updates
> Date: July 18, 2018 at 9:06:17 AM GMT-4
> To: [email-masked]
> Cc: [email-masked]
> 
> I just reread: https://datatracker.ietf.org/doc/html/draft-ietf-ntp-refid-updates and I don’t see the point of leapsmear.  Accurate time is accurate time.  Broken clients are a separate problem.  The best we can do is provide accurate time to them.  If they don’t know what to do with that, that’s their problem, not ours.
> 
> I say with nix leapsmear.
> 
> * * *
> 
> Rather than leaking address information via the REFID field, what about making REFIDs (a) be a hash sufficiently long (say 160 or 256) and (b) making the REFID’s be unique to pair-wise communication, i.e. making them only be relevant to the pair of hosts communicating?
> 
> Host a could advertise nonce_a, and then send a ref-id to b of {nonce_a, hash(nonce_a || address_a || address_b)}.  b would then be able to recompute hash(nonce_a || address_a || address_b) and detect a timing-loop.  nonce_a would be unique for all associations, and hence a malicious third party wouldn’t known nonce_a expect by doing a MITM attack and eavesdropping (or replacing the hashes and nonces).
> 
> For multicast or subnet broadcast mode, address_b would be that address… and hence potentially guessable by an adversary, but most perimeter gateways (firewalls) should be blocking multicast and directed-subnet broadcasts anyway.
> 
> Then we don’t need the NOT-YOU REFID because leaking REFIDs aren’t linkable anyway.
> 
> * * *
> 
> Regarding Section 3.3, I’d put all zeros in the REFID, and mean this to mean “find the REAL REFID” in an an extension field.
> 
> * * *
> 
> I don’t like the idea of REFIDs being overloaded for leap smearing.
> 
> * * *
> 
> -Philip
>

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Wed, 18 Jul 2018 10:50:26 -0400

Since leap-smearing exists and is used it seems better to me to have a way to distinguish the servers that do so. Without an identifier you can’t tell those servers apart from “normal” servers basically until it’s too late.

Ask

-- 
http://askask.com/

---

From: Greg Dowd <[email-masked]>
Date: Wed, 18 Jul 2018 16:14:17 +0000

+1

-----Original Message-----
From: ntp [mailto:[email-masked]] On Behalf Of Ask Bjørn Hansen
Sent: Wednesday, July 18, 2018 7:50 AM
To: Philip Prindeville <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ntp] Resending: Thoughts on draft-ietf-ntp-refid-updates

EXTERNAL EMAIL

Ask

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

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 19 Jul 2018 07:49:40 +0200

>>> Ask Bjørn Hansen <[email-masked]> schrieb am 18.07.2018 um 16:50 in
Nachricht <[email-masked]>:
> Since leap-smearing exists and is used it seems better to me to have a way
to 
> distinguish the servers that do so. Without an identifier you can’t tell 
> those servers apart from “normal” servers basically until it’s too late.
> 

I feel such information is better put into some extension field rather than in
some magic RefID.
BTW: I'd like to see a "ServerID" extension field, bacause with multi-homed
hosts it's hard to find out two different addresses are actually the same
server. Likewise for manycast associations...

---

From: Hal Murray <[email-masked]>
Date: Wed, 18 Jul 2018 23:25:03 -0700

Ulrich Windl said:
> I feel such information is better put into some extension field rather than
> in some magic RefID. 

Is anybody using extension fields today?

Any guesses as to how many clients or servers will break if the reply from a 
server includes an extension field?

-- 
These are my opinions.  I hate spam.

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 19 Jul 2018 09:40:55 +0200

>>> Hal Murray <[email-masked]> schrieb am 19.07.2018 um 08:25 in

> Is anybody using extension fields today?

The point is: Anything suggested for the RefID won't help any software that is running "today". It's all about the future.
> server includes an extension field?

Shouldn't unknown extension fields be ignored?

Regards,
Ulrich

---

From: Ragnar Sundblad <[email-masked]>
Date: Thu, 19 Jul 2018 11:58:51 +0200

I agree with Philip.

1.
I believe a much more relevant time scale to distribute than a leap smeared
one is UT1, as in:
<https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-time-dissemination>
Now, I have no idea how much this is used, but I can easily imagine there
are astrophysicists that appreciate it.

There may possibly be other more relevant ones, like TAI.

So I guess if other time scales than UTC should be allowed, that you should
be able to flag for all of them.

2.
Regarding leap smear, I personally believe it should be done in the client
and not in the server. Today, most unix/linux machines smear an extra leap
second over two seconds. If you want to do it over 20 hours or whatever,
and if you want to avoid telling your untrusted kernel about it, then fine,
handle it as you wish. I understand that modifying the time scale in the
server is an easy way out if you have control also over the servers, I
still don’t think that is a good solution more than in very special confined
cases, and I think it will split the NTP world in two for the entirely wrong
reasons.

I would really like to avoid splitting the NTP world into several different
ones. There is also a high risk that they meet downstream due to
misconfiguration, which will have the clients have bad time and e.g. get
leap seconds even when the operator wanted to avoid that.

(Regarding UT1 etc, I would rather have a good mechanism to distribute
UTC-TAI offsets, UTC-UT1 offsets etc, especially in the UT1 case probably
separate from NTP, maybe also for the TAI case. Maybe it could be done using
(secured) DNS or so, though there should be several “independent” sources.)

Best regards,
/ragge

> On 18 Jul 2018, at 16:34, Philip Prindeville <[email-masked]> wrote:
>

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 19 Jul 2018 12:14:33 +0200

Ask Bjørn Hansen wrote:
> Since leap-smearing exists and is used it seems better to me to have
> a way to distinguish the servers that do so. Without an identifier
> you can’t tell those servers apart from “normal” servers basically
> until it’s too late.
Leap smearing is anyway just a hack to provide a workaround for
limitations of operating systems and applications running on that OS,
which both suffer if the system time is simply stepped back to insert a
leap second.

In the past, the way leap second smearing is implemented has been
changed, e.g. Google did a cosine shape first, then switched to a linear
shape. Other companies used different approaches.

Some time ago I ran some tests which showed that the resulting time
error on a client strongly depends on the client's polling interval and
the total smear interval (which is obvious), but also that at the
beginning and end of the interval a cosine shape results in a smaller
error than a linear shape.

If you are interested see:
https://www.meinbergglobal.com/download/burnicki/ntp_leap_smearing_test_results.pdf

So it wouldn't be sufficient for a client to know *that* leap second
smearing is active, but also *how* smearing is done, i.e. which shape
(e.g. cosine, linear, ...) is used, the total duration (24h, 12 h, ...),
and the time before/after the leap second event (24h/0h, 12h/12h, ...).

I don't see how this information can be put into a basic NTP network
packet, so IMO some extension field(s) would be required to provide this
information.

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: Danny Mayer <[email-masked]>
Date: Thu, 19 Jul 2018 14:37:52 -0400

> Shouldn't unknown extension fields be ignored?

See RFC 7822 Section 7.5.1.*

Danny

---

From: Steven Sommars <[email-masked]>
Date: Thu, 19 Jul 2018 15:15:03 -0500

Figure 18 in http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf
gives a real world example of the leap smearing behavior Martin mentions.

How might a world with a mixture of smeared and non-smeared NTP servers
behave?  Consider some possibilities for a stratum 2+ server (I'll call
this server S2+):

   - (static) Somehow S2+ identifies and configures one of two groups of
   references, either all smear, or all non-smear.
   An individual server is (somehow) not allowed to move between groups.
   The extension field Martin mentions is still needed so that S2+ can
   execute the frequency shifts at the appropriate times
   Without the field, NTP offset errors will increase

   Using static configurations seems error-prone.

   - (dynamic) S2+ uses both smear and non-smear references.   Most of the
   time this works well, but when a leap second is scheduled, operation
   becomes more complicated.  S2+ needs to decide which leap-second style to
   use; possibly this is part of the S2+ NTP configuration.  It also needs the
   leap-second extension fields from upstream servers.
   Sounds like a significant complexity increase in rarely used code.

These considerations also hold for a pure client.

I haven't studied the leap-second smearing in chrony or the reference NTP (
ntp.org).   Perhaps there is an assumption that leap second smearing is
only done on stratum 1 NTP servers.    This wasn't true for the Google
servers, they ran stratum 2 during the December 2016 leap second.

The solution I prefer is to eliminate leap seconds.
If leap seconds remain, either select one method of  mandatory smearing, or
eliminate smearing.
ITU-R seems unlikely to make any decision in the foreseeable future.

Slighly off topic.  An example of reference ID use:    In December 2016 at
least six stratum 2 NTP pool servers were syncing to Google; the
identification was partially based on the reference ID.  I notified the NTP
pool administrator, Ask, who then contacted the server administrators.  The
reference ID trick wouldn't have worked with stratum 3+ pool servers,
however.
Some NTP pool servers were attempting to sync with both smeared and
non-smeared upstream sources; the root dispersion sometimes soared.

Back on topic.  I agree with Martin. The reference ID isn't the place to
communicate leap smearing details.

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Thu, 19 Jul 2018 21:13:56 -0700

On Jul 19, 2018, at 2:58, Ragnar Sundblad <[email-masked]> wrote:

As IETF participants we can choose to ignore something “not quite right” or help make it less wrong. I’m pretty new to this process so I sincerely don’t know what the right choice is, but the status quo around leap seconds is really terrible.

Steven Sommars mentioned the NTP Pool servers that used a leap smearing upstream server. That’s just the tip of the iceberg with regards to leap seconds.

Just speaking for my hobby project it’s something in the ballpark of 10% of the (carefully monitored and otherwise well run!) NTP servers in the system that screw up the leap second one way or the other. Skips it, applies it the wrong direction, applies it at the wrong time, applies it but don’t announce it, etc.

I didn’t look in the monitoring logs, but on the LEAPSECS list Steven posted that he saw several NTP Pool servers that announced the leap second in June. There wasn’t one.

This might all seem unrelated to “should we have a standard for announcing that leaps will be smeared?”; but I think all that brokenness is part of the motivation for having some servers that figured out the hard bits and then have all the other software pretend it’s not happening[1].

To be clear, I’m not suggesting that it has to be in the refid. As Martin points out, that might only cover the most simplistic use case anyway(“I know about leap seconds and don’t want them smeared”).

(Regarding UT1 etc, I would rather have a good mechanism to distribute
UTC-TAI offsets, UTC-UT1 offsets etc, especially in the UT1 case probably
separate from NTP, maybe also for the TAI case. Maybe it could be done using (secured) DNS or so, though there should be several “independent” sources.)

I agree that both TAI-offsets and UT1 would be easier to distribute “out of band” versus having parallel NTP infrastructure for them.

It’s not completely crazy to run a “TAI NTP” and probably someone somewhere does, but the need is MUCH less than the pragmatic need for “time that doesn’t jump a second for seemingly no reason”. (I’m sure if you are running systems that need TAI or UT1 and use those timescales consistently you’d disagree).

If we had a formal (or informal) standard for distributing these offsets over DNS I’d be happy to help with that in my hobby project. We have a surprisingly robust shoe-string operated DNS infrastructure, and ~15 years later some amount of proven record. :-)

Ask

[1] Unless you have non-NTP time sources of course which brings all the complexity back and more if you are smearing.

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Thu, 19 Jul 2018 21:14:16 -0700

To be clear, I’m not suggesting that signaling this has to be in the refid. As Martin points out, that might only cover the most simplistic use case anyway(“I know about leap seconds and don’t want them smeared”).

Ask

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 20 Jul 2018 15:33:29 +0200

>> leap seconds even when the operator wanted to avoid that.

Please don't blame ntpd for smearing leap seconds.

The leap second is inserted/handled by the kernel, and that's basically
the way it should be.

However, this is often done in a way that applications may become
confused if the system time is simply stepped back by 1 s.

If you used any other time synchronization software which just passes a
leap second announcement to the kernel then the applications will have
the same problems.

Leap second smearing by an NTP server is just an optional way to avoid
these problems because there's no better way to get around it.

> Just speaking for my hobby project it’s something in the ballpark of 10% of the (carefully monitored and otherwise well run!) NTP servers in the system that screw up the leap second one way or the…

And ntpd tries to figure it out and avoid this as good as possible. For
example, ntpd ni the role of a client that polls several servers accepts
a leap second announcement only if a majority of the servers announce
the leap second.

Basically the same happens if the upstream servers are a mixture of
smearing an non-smearing servers. During the smear interval the times
received from the servers will drift apart, so if the majority of
servers is non-smearing then the smearing servers will be discarded, but
if the majority of the servers is smearing in the same way they may
overvote the non-smearing server, and the client will adjust its time
according to the smear.

> To be clear, I’m not suggesting that signaling this has to be in the refid. As Martin points out, that might only cover the most simplistic use case anyway(“I know about leap seconds and don’t want…

Actually, the smearing implemented in ntpd changes the refid during the
smear interval in a way that the 32 bit numeric value provides the
current smear offset.

So direct clients of a smearing server can detect that the time is
currently smeared, and even compute and compensate the smearing.

A potential problem is that the smearing server doesn't send a leap
second announcement, so if the client compensated the smear offset it
had to generate the leap second warning for its kernel and its client by
itself.

Another point is that the refid is replaced by a different number in the
packets that smearing server's client sends to its own clients.
I mean it the stratum 1 server is smearing, then a stratum 2 server can
detect this due to the refid received from the S1, but a stratum 3
server which gets the time from the S2 won't see the special refid
representing the smear offset.

This again shows that smearing is an ugly hack, but anyway it's useful
in some specific cases.

> If we had a formal (or informal) standard for distributing these offsets over DNS I’d be happy to help with that in my hobby project. We have a surprisingly robust shoe-string operated DNS infrastr…

Some years ago, Poul-Henning Kamp has already proposed to use DNS to
distribute leap second announcements and the current TAI offset. This is
much easier than distributing a leap second file and standard runtime
library calls can be used to implement this. The idea is to to let a
function like getaddrinfo() resolve a specific hostname, but don't
interpret the returned number as IPv4 address. Instead decode it in a
specific way to extract leap second information and TAI offset from the
returned bit pattern. See:

20151122 - Leapseconds via DNS
http://phk.freebsd.dk/time/20151122.html

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Daniel Franke <[email-masked]>
Date: Fri, 20 Jul 2018 09:47:02 -0400

> these problems because there's no better way to get around it.

In a better world, both NTP time and POSIX time would be TAI-based,
and leap second updates would be handled through the time zone
facility, with UTC being just another local time zone. Alas, that ship
sailed away a long time ago.

In a slightly worse world still better than the current one, NTP would
provide unsmeared time to the kernel, which would provide smeared time
through the what-ought-to-be-legacy POSIX APIs, and unsmeared time
through a new better-designed API that expresses time as
whole-days-since-epoch + seconds-since midnight, so that time can be
expressed unambiguously during leap seconds. That ship, too, has
lifted anchor, but maybe it's not too late to jump onto it.

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Jul 2018 14:55:00 +0100

Martin Burnicki <[email-masked]> wrote:
> Ask Bjørn Hansen wrote:
> >
> > If we had a formal (or informal) standard for distributing these
> > offsets over DNS I’d be happy to help with that in my hobby project.
> > We have a surprisingly robust shoe-string operated DNS infrastructure,
> > and ~15 years later some amount of proven record. :-)
>

I have a slightly different take on this idea: I distribute the complete
leap second table at leapsecond.dotat.at in various formats including
phk-style IPv4 addresses, human-readable IPv6 addresses, and a relatively
terse TXT record. e.g.

$ dig +short leapsecond.dotat.at aaaa | sed 's/:6:/:06:/' | sort
::1972:06:30:23:59:60
::1972:12:31:23:59:60
::1973:12:31:23:59:60
::1974:12:31:23:59:60
::1975:12:31:23:59:60
::1976:12:31:23:59:60
::1977:12:31:23:59:60
::1978:12:31:23:59:60
::1979:12:31:23:59:60
::1981:06:30:23:59:60
::1982:06:30:23:59:60
::1983:06:30:23:59:60
::1985:06:30:23:59:60
::1987:12:31:23:59:60
::1989:12:31:23:59:60
::1990:12:31:23:59:60
::1992:06:30:23:59:60
::1993:06:30:23:59:60
::1994:06:30:23:59:60
::1995:12:31:23:59:60
::1997:06:30:23:59:60
::1998:12:31:23:59:60
::2005:12:31:23:59:60
::2008:12:31:23:59:60
::2012:06:30:23:59:60
::2015:06:30:23:59:60
::2016:12:31:23:59:60
::2019:06:27:23:59:59

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
fight poverty, oppression, hunger, ignorance, disease, and aggression

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 20 Jul 2018 15:55:35 +0200

> are astrophysicists that appreciate it.

If you use this with a standard NTP client then your system time will be
UT1 instead of UTC.

> be able to flag for all of them.

And the question is: where to put the flag? If you actually need UTC as
a basis for the local time zones then you don't just need a leap second
warning, but also the current UTC/TAI offset.

> and not in the server.

Hm, I think it depends on the situation. ;-)

> Today, most unix/linux machines smear an extra leap
> second over two seconds.

Hm, I haven't seen any Unix kernel that does so. Do you have an example?

All I've yet seen on Unix-like systems is that the time is simply
stepped back by 1 s to insert a leap second.

However, the Windows port of ntpd does this on Windows, because except
the next Windows Server version (Server 2019) and associated future
Windows 10 versions, there's no leap second support at all in Windows.

> If you want to do it over 20 hours or whatever,

It's indeed just a hack, but if you can let the server do the smearing
you don't have to fiddle with the configuration on every single client,
which caused much work, specifically in a huge network with many clients.

See also my reply to Ask.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 20 Jul 2018 16:00:24 +0200

> sailed away a long time ago.

Unfortunately, yes.

> lifted anchor, but maybe it's not too late to jump onto it.

Again, I absolutely agree with you.

However, Steve Summit has proposed a kernel patch which introduces some
new clock IDs for clock_gettime(), which return the time according to
different "clock models", including a time smeared by the kernel.

This sounds like a good solution to me.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 20 Jul 2018 16:07:11 +0200

> $ dig +short leapsecond.dotat.at aaaa | sed 's/:6:/:06:/' | sort

This also sounds like a good idea, IMO.

The problem is that there is no progress in making things like this more
public. PHK has suggested this back in 2015 (IIRC), and I've heard
nothing else about this since.

If something like this should become a well accepted feature, there's
also the question who runs and maintains the top level DNS entry in a
reliable way? It must be made sure that the DNS entries are well
maintained and updated over a long time, not only for the next 2 years
or so, as long as some volunteers are interested in this topic.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Jul 2018 18:27:18 +0100

> or so, as long as some volunteers are interested in this topic.

Yes, it's a problem. The best I can do is write a maintenance script that
is mostly automated, and verifies that the IERS, USNO, and NIST leapsecond
tables agree before it will update the DNS. But, as you correctly observe,
I'm just an easily distracted volunteer :-)

(warning: symbiosisware ahead, danger will robinson!)
http://dotat.at/cgi/git/leapseconds.git/blob/HEAD:/leapseconds.pl

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger: Variable 3 or 4. Slight. Occasional
rain or showers. Good, occasionally moderate.

---

From: Warner Losh <[email-masked]>
Date: Fri, 20 Jul 2018 11:42:38 -0600

> > sailed away a long time ago.

Agreed. Though that path is not without it's own peril for disconnected
systems that need to sit on the shelf and act as hot spares (not the
most-common problem, but it's illustrative of the edge cases that crop up
and likely not the only one). I think it would be much better and have an
order of magnitude fewer problems than the crazy we have today.  I'd add to
that some authenticated source of truth for leap seconds over the net in a
standardized format, since we're already asking for ponies :)

Warner

---

From: Tony Finch <[email-masked]>
Date: Fri, 20 Jul 2018 19:32:54 +0100

Warner Losh <[email-masked]> wrote:
>
> I'd add to that some authenticated source of truth for leap seconds over
> the net in a standardized format, since we're already asking for ponies
> :)

My zone with the leapsecond records is signed with DNSSEC, but you might
argue whether the signatures authenticate what you want them to :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides: Northwest 3 or 4 backing southwest 4 or 5,
occasionally 6 later in Hebrides. Slight or moderate. Drizzle and fog patches,
mainly later. Moderate or good, occasionally very poor later.

---

From: Ragnar Sundblad <[email-masked]>
Date: Sat, 21 Jul 2018 02:04:14 +0200

> On 20 Jul 2018, at 15:33, Martin Burnicki <[email-masked]> wrote:
> 
> Ask Bjørn Hansen wrote:
>> 

I certainly don’t.

> The leap second is inserted/handled by the kernel, and that's basically

There are many ways that this could be handled, that is just one of them.

If you want to do it over 20 hours or whatever, that could be done with
the current kernel API as well, which is actually exactly what happens
with the current violating smeared NTP time scales, just that the NTP
clients are not aware that they are tricked into doing this.

There is still no need to set up a separate public NTP distribution
systems with separate time scales just to get this behaviour.

> these problems because there's no better way to get around it.

There are many ways that don’t involve separate NTP networks with
different time scales. But for some applications, this was the fastest
solution, especially since "someone else" had already done the work
and you just needed a configuration change, and this was at a time
when many didn’t trust their kernels of a certain brand since it
had problems before, if you were unlucky resulting in deadlocking.

> On 20 Jul 2018, at 15:55, Martin Burnicki <[email-masked]> wrote:
> 
> Ragnar Sundblad wrote:
>> 
>> I agree with Philip.
>> 
>> 1.

Correct.

Some people only care about UT1 in their applications. This is a timescale
that has to be distributed in real time or at least pretty often,
depending on your application, and which actually may be a proper use
case for a time distribution system like NTP.

Leap second smearing, which is just a workaround for broken software,
isn’t.

> warning, but also the current UTC/TAI offset.

Right. That is why I wonder if it is wise to have a special “smeared
timescale” flag and not having similar flags for other time scales.

But I do believe the answer is that NTP on the public internet should
always carry UTC for now, and that all conversions to other time scales
should be a local thing.

> Hm, I think it depends on the situation. ;-)

I strongly believe we need to have a defined time scale in NTP, or NTP
is worth nothing. RFC 5905 mentions UTC several times, so that should
be it.

If someone starts to distribute other time scales, they should not be
possible to mix up by mistake, as is the case today.

Regarding leap seconds, that information already is distributed in
NTP, and there is absolutely no reason to set up separate public
NTP systems with smeared time.

> stepped back by 1 s to insert a leap second.

Right, “smear” was not the correct term here. But it could very well
be implemented by just letting the clock go at half speed for 2 seconds,
or at 1s/20h speed for 20 hours. It should be up to the owner of the
box to choose which kind of headache she/he prefers (sadly, because of
the lacking API:s and all the broken software out there).

> which caused much work, specifically in a huge network with many clients.

If you have a large network of machines that implements a large application,
setting up leap second smearing style on the boxes is a non issue.
It is one of hundreds or thousands of things that have to be configured
to have your boxes do you want them to do.

/ragge

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 23 Jul 2018 08:12:38 +0200

>>> Daniel Franke <[email-masked]> schrieb am 20.07.2018 um 15:47 in
Nachricht
<[email-masked]>:
> In a better world, both NTP time and POSIX time would be TAI‑based,

There may be an problem for embedded devices, however: As obviously your
proposal requires that timezone data is provided (and installed) significant
time before a leap second occurs, I see a problem with embedded devices, as
those see software updates quite infrequently (if at all).

> through the what‑ought‑to‑be‑legacy POSIX APIs, and unsmeared time
> through a new better‑designed API that expresses time as
> whole‑days‑since‑epoch + seconds‑since midnight, so that time can be

Actually what I was thinking is: Why npt start to adjust the duration of a
second once the leap second is announced (6 months ahead)? That way no normal
system will ever notice. The disadvantage is that all refclock systems will
have to agree on it. That's quite unlikely, however, especially for GPS...

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 23 Jul 2018 09:11:46 +0200

>>> "Ulrich Windl" <[email-masked]> schrieb am 23.07.2018 um
08:12 in Nachricht <[email-masked]>:
[...]
> Actually what I was thinking is: Why npt start to adjust the duration of a

s/npt/not/ #Sorry!