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

[Ragnar Sundblad <[e-mail]>]

> On 20 Jul 2018, at 15:33, Martin Burnicki <[e-mail]> wrote:
> 
> Ask Bjørn Hansen wrote:
>> 
>>> On Jul 19, 2018, at 2:58, Ragnar Sundblad <[e-mail]> wrote:
>>> 
>>> 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.
> 
> Please don't blame ntpd for smearing leap seconds.

I certainly don’t.

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

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.

> 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.

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 <[e-mail]> wrote:
> 
> Ragnar Sundblad wrote:
>> 
>> 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.
> 
> If you use this with a standard NTP client then your system time will be
> UT1 instead of UTC.

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.

>> 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.
> 
> 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.

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.

>> 2.
>> Regarding leap smear, I personally believe it should be done in the client
>> and not in the server.
> 
> 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.

>> 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.

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).

> 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,
>> 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.
> 
> 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.

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