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

[Watson Ladd <[e-mail]>]

On Mon, Jan 4, 2021 at 7:40 PM Philip Prindeville <
[e-mail]> wrote:
<chop>
> > 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.

Unfortunately that is not the cas: the usual time functions return Unix
time, which loses information compared to UTC, and therefore cannot be
translated into TAI.  ntp_adjtime seems to be the best candidate from a
portability perspective but may only be callable by privileged processes
even when trying to read the current time. It also can't be used when
software or hardware timestamping of packets is being used since the
structure that is returned from those functions is a timespec, which
doesn't have a leap second indicator.

When discussing hardware the situation is somewhat better as network cards
use PTP which distributes TAI, and some have support for stamping with it.

The other problem is that in kernel steering can introduce stability issues
compared to userspace steering as Miroslav demonstrated for us some time
ago.

Sincerely,
Watson Ladd