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

[Magnus Danielson <[e-mail]>]

On 2021-01-05 08:20, Ulrich Windl wrote:
>>>> 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:
>>
>> 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.

Well, there is a long line of technical decisions spread over a long time.

For instance, the fact that the NTP time would mimic the time_t behavior
on leap seconds is one very clear case where a specific user behavior
was pushed onto the on the wire protocol.

Then, the original nanokernel interface was concerned with scheduling
issues and the state of time-stamp mechanisms available at that time. We
have since gained access to several additional time-stamp mechanisms
even in user-space, both running as counter on the bus-clock and
CPU-clock cycles, the later which may vary over time due to dynamic
cycle handling to avoid overheating.

Then, the notion that we want to also keep the TAI-UTC difference, and
that this would allow for a CLOCK_TAI in the first place. However, as
that was added, it was the TAI-UTC difference that was added to the
Autokey transport (but never really to the Autokey itself).

The pre TAI-UTC difference version of the nanokernel interface was for a
long time stuck in the glibc headers not being updated, despite the
linux kernel had the capability for it. Again illustrating how a
side-channel became problematic rather than a solution, which I keep
having to point out is an issue.

So, yeah, it became ugly for sure, but it was a consequence of history,
not because it was inherently bad. I think the proper lesson to learn is
to actually build for it from the start. Then if it is implemented in
the kernel or in libc for a particular operating system, well that I
think is not what the working ground should care about as such, but we
can discuss it. I think it is not inherently bad to keep both TAI and
UTC sense in the kernel, and I am much more keener to push out UTC in
that case than TAI. The low-hanging fruit for UNIX/Linux type operating
systems would be to use the PTP time definition, then you could move UTC
adaptation and classical time_t variants out of the kernel and only use
the new time_t internally. The needed things in libc would be fairly
trivial. A common way to access the TAI-UTC difference is however
needed, one could let the kernel take on that task only for practical
reasons, but really not process on them itself. That provides fairly
small burden, but then again, that would be an implementational detail
for the OS, that we can hide behind libc, as long as we can do the right
things and access it all the times. The overall requirements for such
interface contains a bit of details to know if we "have" things right
now and it's error handling, but not very complex. Using a form of
nanokernel interface to steer the rate of the system time, is probably
still a good idea, but I think reposition the problem will simplify it
significantly.

So, make sure to learn the right things from history.

Cheers,
Magnus