[Ntp] Antw: [EXT] Re: NTPv5: big picture

[Ulrich Windl <[e-mail]>]

>>> Magnus Danielson <[e-mail]> schrieb am 04.01.2021 um 19:00 in
Nachricht <[e-mail]>:
> Philip,
> 
> On 2021-01-04 18:40, Philip Prindeville wrote:
>>
>>> On Jan 4, 2021, at 8:18 AM, Miroslav Lichvar <[e-mail]> wrote:
>>>
>>> On Thu, Dec 31, 2020 at 06:54:40PM -0800, Hal Murray wrote:
>>>> Do we have a unifying theme?  Can you describe why we are working on
NTPv5 
> in 
>>>> one sentence?
>>> There is a list of issues in NTPv4 I would like to see fixed in NTPv5:
>>> https://trac.ietf.org/trac/ntp/wiki/NtpVersionFourIssues 
>>>
>>> A major issue is that NTPv4 doesn't support short extension fields due
>>> to conflicts with legacy MACs, so fixing all those issues by adding
>>> new extending fields to NTPv4 seems impractical. Some things, e.g. the
>>> timescale selection, makes more sense to have in the header.
>>>
>>>> Part of the motivation for this is to enable and encourage OSes to
convert 
> to 
>>>> non-leaping time in the kernels.  Are there any subtle details in this
area 
>>>> that we should be aware of?  Who should we coordinate with?  ...
>>> I don't think that should be the job of the NTP WG. The kernels will
>>> need to support a leaping UTC timescale for as long as it is needed
>>> for civil time.
>>
>> I disagree.  The kernel doesn’t inherently require UTC.  It could just as 
> easily use TAI or some other format.
>>
>> The kernel needs to provide into user-space some format which is then 
> convertible to UTC, for as long as UTC is in-use by applications.
>>
>> This could be handled by libc.
> 
> While I agree that kernel very well could operate in some suitable TAI
> format, and the PTP scale would be the low-hanging fruit for that, as it
> intends to be that blend of TAI and classical UNIX/POSIX time_t.
> 
> However, the only way I know with spreading in which TAI and UTC is
> maintained is through the kernel interface provided by the NTP
> nanokernel, and that is supported on effectively most Linuxes.

Now that you mention it: I think it was also a bad design in NTPv4 to require
a nanokernel to handle TAI: Instead of storing and reading the TAI in/from the
kernel, the daemon should have a "working copy". The other bad thing was that
TAI processing was tied to autokey protocol extensions.

> 
> What can be done better is to use it properly and that libc would
> provide the needed glue. If libc does that, then from the user's point,
> if this is done completely in libc or shared between kernel and libc the
> user do not care, as long as they get correct time-stamp and the machine
> is setup to feed the needed data.
> 
> But then again, I do not think it's the NTP WG job do decide where it is
> implemented, rather we shall make sure the NTP side of things can
> support the needed features so that it works well.
> 
> Cheers,
> Magnus
> 
> _______________________________________________
> ntp mailing list
> [e-mail] 
> https://www.ietf.org/mailman/listinfo/ntp