Re: [Ntp] Timescales, leapseconds and smearing

[Martin Burnicki <[e-mail]>]

Kurt Roeckx wrote:
> On Mon, Dec 07, 2020 at 11:27:35PM +0100, Kurt Roeckx wrote:
>>
>> An other way to fix the non-continues problem is to have some
>> indication of on which scale you are. It needs to be able to say
>> in which scale each of the timestamps is. The proposed draft has a
>> TAI-UTC offset if you use the NTP scale that could be used for this,
>> but it would then apply to both timestamps. If that is what we
>> want to do, it needs to be more clear. But for the UT1 scale there
>> is no way to indicate it.
> 
> One thing I forgot to mention is that if there can be doubt about
> what the timestamp field means, the packet could just be dropped,
> so from 1 second before the leap second, to 1 second after the
> leap second, for a total of 3 seconds.

AS said earlier, ntpd from ntp.org does this. It sets the leap bits to
"unsynchronized" so the client sees that it gets a reply, but (with
usual poll intervals) a single reply to be dropped.

This avoids huge time offsets that could occur e.g. if the kernel steps
the time back just after the server has grabbed a receive timestamp for
a request, and before it grabs another timestamp as the transmit time.

>> NTP could distribute information about difference between
>> timescales. A leap second will change the offsets, so we already
>> do this in a very limited way. TAI-UTC and UT1-UTC are mentioned in
>> the proposed draft, but it depends on which timescale you're using
>> which offset you can get. I'm not sure NTP is the best way to
>> distribute it. But for a lot of devices NTP is the only source of a
>> leap second information.
> 
> I guess that should say current leap second information. There is
> of course a class of devices that should use SNTP and so don't
> really care about the leap second. But there probably are also
> devices that do care about it, have the option to get it, but
> don't get it.

As far as I can tell, most NTP clients just run fine if they receive a
leap second warning from the server early enough.

What happens at the client side if the kernel just steps the time back,
and if e.g. databases get a hickup because the time is stepped back is
IMO a problem of the operating system and the applications, which in
fact goes back to the deficiencies of the POSIX time specification.


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