[Ntp] Antw: Re: Antw: [EXT] Re: CLOCK_TAI (was NTPv5: big picture)

[Ulrich Windl <[e-mail]>]

>>> Doug Arnold <[e-mail]> schrieb am 08.01.2021 um 16:17
in
Nachricht <[e-mail]>:
> I think that the point of a leap smear is that no special handling of leap 
> seconds is needed by the client.  It is introduced gradually over a number
of 
> polling periods.

But if you have two servers using leap smear, and to servers not using leap
smear, all will claim to return the correct time one second after the leap
event.
With the same logic as claiming UNSYNC during theleap event for non-smearing
servers, smearing servers should return UNSYNC until the time is "correct"
again IMHO.

Regards,
Ulrich


> 
> Doug
> 
> On 1/8/21, 2:32 AM, "ntp on behalf of Ulrich Windl" <[e-mail]
on 
> behalf of [e-mail]> wrote:
> 
>     >>> Martin Burnicki <martin.burnicki=[e-mail]>
schrieb am
>     07.01.2021 um 16:55 in Nachricht
>     <[e-mail]>:
>     > Miroslav Lichvar wrote:
>     >> On Wed, Jan 06, 2021 at 09:57:56AM +0000, FUSTE Emmanuel wrote:
>     >>>
>     >>> I clearly don't understand the resistance to go to a linear TAI like

>     >>> form for the core time-stamping format as long as the TAI-UTC offset
is 
> 
>     >>> part of the core protocol frame.
>     >> 
>     >> That offset is not always available, e.g. with a DCF77 refclock.
>     >> Relying on other sources is not always acceptable.
>     >> 
>     >>> You will have to do some conversions and adaptations in the OS 
>     >>> adaptation layer, as today for all NTP implementations, and this
layer 
>     >>> will not be messier as the core is today. No need to wait that 
> operating 
>     >>> systems fully support a non-leaping timescale, or TAI-UTC offset
>     natively.
>     >> 
>     >> No, it will be messier. That's the other problem.
>     >> 
>     >> If your OS doesn't have a TAI clock or it doesn't support
timestamping
>     >> with the TAI clock, you will have to resolve the ambiguity in your
NTP
>     >> implementation. That will not be 100% reliable as you cannot be sure
>     >> if the timestamp is captured before or after the leap. You are only
>     >> guessing. If the client doesn't know that the server is only
guessing,
>     >> it may get unexpected errors in measurements and its clock
disrupted.
>     >> 
>     >> The best thing you can do on such an OS is to suspend the operation
>     >> around leap second, the same thing as when using a leaping
timescale.
> 
>     Does "around the leap second" mean "until leap smear is complete" in 
> case of
>     leap smearing?
> 
>     >> In other words, there is no advantage of using a non-leaping
timescale
>     >> for the time transfer. It would only make things even more messier
>     >> than they already are.
>     > 
>     > Once more, I strongly agree.
>     > 
>     > Martin
>     > -- 
>     > Martin Burnicki
>     > 
>     > Senior Software Engineer
>     > 
>     > MEINBERG Funkuhren GmbH & Co. KG
>     > Email: [e-mail] 
>     > Phone: [phone]
>     > Linkedin: https://www.linkedin.com/in/martinburnicki/ 
>     > 
>     > Lange Wand 9, 31812 Bad Pyrmont, Germany
>     > Amtsgericht Hannover 17HRA 100322
>     > Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
>     > Andre Hartmann, Heiko Gerstung
>     > Websites: https://www.meinberg.de  https://www.meinbergglobal.com 
>     > Training: https://www.meinberg.academy 
>     > 
>     > _______________________________________________
>     > ntp mailing list
>     > [e-mail] 
>     > https://www.ietf.org/mailman/listinfo/ntp 
> 
> 
> 
>     _______________________________________________
>     ntp mailing list
>     [e-mail] 
>     https://www.ietf.org/mailman/listinfo/ntp