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

[Philip Prindeville <[e-mail]>]

> 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.


> 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.

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.

-Philip



> If someone has an issue for another way to
> implement, sure we try to resolve that. The WG should however not
> specify how that should be done, and that was the actual question at
> hand which I discussed.
> 
>> FreeBSD is as good a platform as any to demonstrate one of those implementations.
> 
> For sure. That was not the topic at all.
> 
> Cheers,
> Magnus