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

[Magnus Danielson <[e-mail]>]

Philip,

On 2021-01-05 04:40, Philip Prindeville wrote:
>
>> On Jan 4, 2021, at 4:03 PM, Magnus Danielson <[e-mail]> wrote:
>>
>> Philip,
>>
>> On 2021-01-04 21:33, Philip Prindeville wrote:
>>>> On Jan 4, 2021, at 1:21 PM, Magnus Danielson <[e-mail]> wrote:
>>>>
>>>> Warner,
>>>>
>>>> On 2021-01-04 19:29, Warner Losh wrote:
>>>>> On Mon, Jan 4, 2021 at 9:34 AM Magnus Danielson <[e-mail]> wrote:
>>>>>> It's not in NetBSD or FreeBSD.
>>>>> Unfortunately not. However, that could probably be changed if enough
>>>>> interest exists.
>>>>>
>>>>> There were a number of issues with it in Linux.
>>>> What issues are these that you refer to?
>>>>> If there's a clearer definition of what it should be and how things should be updated as leap second knowledge evolves, I'd be happy to get it into FreeBSD...
>>>> I think that part of the discussion is really not part of NTP WG discussion, but I am sure things can be figured out.
>>>>
>>> Again, disagree.  I remember the days of the IETF where (1) a document describing a protocol was required, and (2) a successful “bake-off” demonstrating 3 unrelated interoperating implementations was equally required…
>> Which is fine if it was relevant, which it really isn't.
>>
>> The details of how various implementations choose to do things is really
>> not what the protocol should go into, but it is good that the protocol
>> and details is done so the implementation becomes feasible. Wither the
>> kernel use TAI only or can handle various time-scales in parallel is in
>> my mind to very much degree an implementation detail.
>
> It’s as relevant as it’s ever (always) been: the implementations are in theory to be written “blind” with only the proposed RFC to guide the developers.  If the RFC isn’t sufficiently clear for at least 3 implementations to converge on a common interpretation, then it’s not adequately explained.
>
> I’m not talking about TAI being what the kernel uses; I’ve been talking about the on-the-wire canonical representation of time.
Trouble is, this particular thread started out with a discussion of what
the kernel should do, and I objected to the NTP WG to dictate what a
particular implementation would do. The protocol on the wire is a
different thing, that is for sure what the NTP WG should care about.
>> There Linux and
>> BSD can make different approaches with various benefits, and this is why
>> you want at least two implementations, with assumed different
>> implementation decisions, to bring it up on the standard track so that
>> you learned something. There are many ways to implement things, and not
>> all involve even the kernel to be involved at all. So, I think the
>> discussion about how the kernel handling things in itself is not the NTP
>> WG issue, other than showing it's feasible to do. If we agree that it's
>> feasible, we move on.
>
> That’s not what I was saying at all.  It was pointed out that the kernel uses UTC internally.
Actually, they do not use UTC internally, except some under very
specific conditions.
>
> I replied pointing out that (1) it doesn’t matter what the kernel uses internally if applications can get whatever time they need through run-time support (i.e. libraries like libc) and (2) internally the Linux kernel at least (and I figure most POSIX compliant kernels) are capable of maintaining multiple timescales.  As long as whatever the clock runs in natively can be converted unambiguously into any other format, it doesn’t matter which is used.
>
> For the sake of the kernel, the notion (or distinction) of days, years, and leap-days seems to be arbitrary or even irrelevant.
>
> All the kernel really cares about is maintaining accurate, stable, unambiguous time which can then be converted to the timescale being requested by a process in user-space.
>
> And because of this freedom, NTP can use whatever timescale it wants on-the-wire… and the kernel can likewise independently use whatever timescale it wants to use internally… as long as there’s a mechanism to convert to whatever applications want.
>
> I hear people repeating that the kernel, the protocol, and applications all need to use the same timescale.  They don’t.  This is a fallacy.

Agree, it's a fallacy indeed. I have tried to make that very point.

The particular thread started out with an ambition to steer how kernel
implement things, that I think is outside the scope of the WG. What is
inside is that regardless of how it is implemented, the needed
definitions, information and similar is provided such that
implementations (the notion kernel and user space may actually be
completely irrelevant in some implementations) can reasonably be
implemented, both in clarity and consistency.

If the NTP WG feels like it, it can provide informal information to
guide implementors, at least for some model. That is usually handy, as
it tends to provide alternative explanation of things fits together.
Here the NTPD implementation has acted as the reference, the golden
standard if you so like. Trouble is, it attempts to be both reference
implementation and the actual implementation. This can be troublesome,
as the reference part becomes obscured by the many details of real life.
This is not to say that NTPD is not without value, but it is problematic
in terms of reference implementation in this regard. There is quite a
bit of reading to do to be able to penetrate the many things going into
it. Dave Mills provides information in books and webpages for sure, I
have seen far worse examples, but one could consider a somewhat cleaner
slate.

Cheers,
Magnus