Re: [Ntp] Timescales, leapseconds and smearing

[Martin Burnicki <[e-mail]>]

Miroslav Lichvar wrote:
> On Mon, Dec 07, 2020 at 11:27:35PM +0100, Kurt Roeckx wrote:
>> The proposed draft has support for the first 4, and offsets
>> between some of them. Note that it calls the NTP timescale
>> UTC, which it's not.
> 
> How do you suggest it should be called?

In fact, it's like POSIX time but with a different epoch. Is POSIX time
UTC? ;-)

I've seen other programming environments where time_t directly returned
seconds since 1900, not 1970. If I remember correctly, LabWindows CVI is
such a system.

>> - There is a need to distribute information about when a leap second
>>   will happen, which for can happen over NTP or some other way.
>>   Experience shows that a lot of NTP servers get this wrong,
>>   resulting in synchronization problems when some servers change
>>   and others not. When distributed over NTP, a majority of the
>>   servers need to indicate that it will happen. There is no way
>>   to indicate that you don't know a leap second will happen or
>>   not, making it harder to get it correct.
> 
> That's a good point. It would help have a special value, or a flag,
> for the unknown case.

In the past, the reason for the problems with leap second announcements
were firmware bug in GPS receivers (or in ntpd in one case).

So when would that special value be used?

In case if a leap second file is available, but has expired?

In case a GPS receiver is used but it is impossible to retrieve the leap
second/TAI info from the receiver? For example, as far as I know there
is no NMEA sentence that transports the leap second / TAI information
that is available inside the receiver.

>> 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.
> 
> The draft says the offset is for the receive timestamp. The client can
> calculate it for the transmit timestamp in the non-ambiguous
> timescales.
> 
> If the client cares about the ambiguity, it should use a non-ambiguous
> timescale. Of course, both server and client need to support that.
> Clients using ambiguous timescales can be recommended to ignore any
> measurements around the leap second, as some current implementations
> do.
> 
>> I'm currently not sure if we should do something with smearing. We
>> could for instance say that even if the server is smearing, NTP
>> should always contain unsmeared time, and that smearing is an
>> implementation detail. Or we could standardize how it should be
>> smeared. Or like the current draft that you have smear offset.
> 
> We should consider the reasons why server leap smearing is currently
> used. I think the main one is that most NTP clients cannot be
> configured to correct the clock for a leap second by a controlled
> slew. If they could do that, there would be no need to do it on the
> server.
> 
> If NTPv5 had a special leap-smeared timescale, would be the clients
> actually updated to request it? I doubt it.

I agree. As mentioned earlier, this is used to send faked time to the
clients to totally hide the leap second.

If a client was aware that it couldn't handle a leap second properly, it
could do the smearing by itself, locally.

Using a smearing server makes thing easier because there's only the
server that needs to be modified, and all clients of that server behave
in the same way.

> Maybe it would be better to just have a single flag for the server to
> announce it is implementing a leap-smear. Clients could at least
> detect mixing of smearing and non-smearing servers and better handle
> the case when it knows about the leap second from a separate source.

As said earlier, ntpd from ntp.org already sends a special refid while
sending smeared time, so "intelligent" clients already could detect and
compensate the smearing.


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