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

[Harlan Stenn <[e-mail]>]

I'm kinda sadly surprised that we're even having this conversation.

On 7/11/2023 11:57 PM, Windl, Ulrich wrote:
> Hi!
> 
> Actually in our intranet we have at least one device claiming to use NTPv2.

Is it claiming v2 or is it actually running code from before June of 1993?

Why did you mention this without doing any additional investigation of 
the situation?   What is your goal?

> So your recommendations might seem nice, but actual implementations may be different.

If you are using something other than the reference implementation, you 
should follow the instructions for that software.

TTBOMK, there is no ubiquitous program named 'ntpdate'.  Do you disagree?

The only pervasive version of ntpdate that I know of is the one in the 
reference implementation, and we have been telling folks for a 
disturbingly long time that they should not use ntpdate, and have given 
what, to me, sure looks like simple, clear, and complete direction on 
what should be used instead of ntpdate.

> There still is amazingly terrible software around.

Sure.  So what?

Why are "you" trying to perpetuate a known-bad "solution"?

H
--
> Regards,
> Ulrich
> 
> -----Original Message-----
> From: Harlan Stenn <[e-mail]>
> Sent: Wednesday, July 12, 2023 8:52 AM
> To: Windl, Ulrich <[e-mail]>; Martin Burnicki <[e-mail]>; Daniel Franke <[e-mail]>; Miroslav Lichvar <[e-mail]>
> Cc: Dieter Sibold <[e-mail]>; NTP WG <[e-mail]>
> Subject: [EXT] Re: [Ntp] Re: Re: Consensus call: NTPv5 and leap second smearing
> 
> Nobody should be using ntpdate.
> 
> The correct procedure for this has been well-documented for many years'
> time.
> 
> H
> 
> On 7/11/2023 11:29 PM, Windl, Ulrich wrote:
>> Hi!
>>
>> On "I wonder how big the chance is that you will run ntpdate or something to
>> initially set your sytem time exactly during this short interval, so it
>> can be affected by this tiny modification.":
>> Like for race conditions: The question is not *how* likely it is; instead the fact that it is possible is enough to worry about it.
>>
>> Some embedded systems have no battery backed clocks, so they try to get the time from network during boot, and they typically use some "ntpdate equivalent" that will query a bunch of servers once, the "take the best one" to set the time. That was the scenario I had in mind.
>>
>> Regards,
>> Ulrich
>>
>> -----Original Message-----
>> From: Martin Burnicki <[e-mail]>
>> Sent: Tuesday, July 11, 2023 4:29 PM
>> To: Windl, Ulrich <[e-mail]>; Daniel Franke <[e-mail]>; Miroslav Lichvar <[e-mail]>
>> Cc: Dieter Sibold <[e-mail]>; NTP WG <[e-mail]>
>> Subject: [EXT] Re: [Ntp] Re: Consensus call: NTPv5 and leap second smearing
>>
>> Ulrich,
>>
>> Am 11.07.23 um 08:11 schrieb Windl, Ulrich:
>>> Hi!
>>>
>>> I'm not so sure about that: Assume there's a leap second going on, and some client using SNTP (ntpdate) on boot to set the time.
>>> According to the protocol a server saying UNSYNC cannot be used, so around leap event no time sync is possible then. Right?
>>
>> If I remember correctly, doing so has been proposed by Miroslav quite
>> some time ago, and in ntpd from ntp.org it has been implemented accordingly.
>>
>> There are only about 3 seconds (IIRC) around a leap second where a
>> server claims to not being synchronized.
>>
>> If a normal clients that polls once every 64 s (or in even larger
>> intervals) happens to do a poll exactly during these 3 seconds, it gets
>> a single reply from the server which the client will simply ignore.
>>
>> If the server would *not* claim to be unsynchronized, there's a chance
>> that the client has already made the leap second step, but the server
>> has not, or vice versa. In this case, a continuous offset that used to
>> be in a sub-millisecond range could easily increase to about 1 second
>> for this single poll.
>>
>> Of course this could be eliminated by a spike filter, but I agree with
>> Miroslav that possible impacts are much less if such a huge spike can't
>> even occur.
>>
>> I wonder how big the chance is that you will run ntpdate or something to
>> initially set your sytem time exactly during this short interval, so it
>> can be affected by this tiny modification.
>>
>>
>> Martin
> 

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!