Re: [Ntp] Comments on Miroslav's NTP v5 proposal.

[Miroslav Lichvar <[e-mail]>]

On Sun, Nov 15, 2020 at 11:35:02PM -0800, Watson Ladd wrote:
> The following are unsorted, rough comments. I agree sending them
> outright before the meeting is probably suboptimal, but I need
> something to do to keep me awake to the meeting. Obviously this is an
> early draft, and I hope my suggestions are read as contributions not
> criticisms.

Thanks for the comments.

> The data types need some evocative names. Maybe shim for the 16 bit
> one? Not sure what works for the 32 bit one?

I have no good suggestions here. Maybe "short", "medium", and "long"?

> The distribution of multiple scales needs some careful thought,
> especially leap smearing. Insofar as we need monotonic clocks, I'm
> contemplating MJD as a basis for solving the problems leap smearing
> were supposed to solve, but we might be stuck with leap smearing due
> to the install base.

It's not clear to me how timestamps in a MJD-based format would help.

The "Monotonic Timestamp" from the draft is not supposed to have an
epoch and it actually doesn't need to be from a monotonic clock. I can
see how this could be confusing. There should be a better name for
this timestamp and concept.

> I'm not sure UT1 deserves a timescale. It's a comparatively slow
> moving offset from UTC, updated every month. Would an extension to
> propagate this difference work instead?

How would an extension be better? Are you worried we will need more
than 16 timescales, which wouldn't fit in the 4-bit field?

There must be some demand for UT1 as NIST runs UT1-based NTP servers.
That's the main reason why I put it there. I guess it's very
convenient for some astronomers.

> If Root Delay and Root Dispersion are propagated something needs to be
> said about their proper updating. These values are used in source
> selection, and so some degree of agreement across implementations is
> desirable.

I'd like to have a section on the metrics. Explain how they are
supposed to work and where they can be used, but unlike RFC5905 not
enforce any particular model of the clock.

> The monotonic additional timestamps are an intriguing idea but I'd
> like to know more about it. In particular the frequency to be
> distributed seems pretty awkward. Maybe I'm imagining the application
> entirely incorrectly.

The goal is to give clients two separate signals so they can better
measure their phase and frequency offsets. With a single signal there
is always a compromise between phase and frequency accuracy, which
leads to various issues.

As a simple example, consider the kernel PLL used by ntpd. The
monotonic timestamp could be set to the current system time adjusted
by the current PLL offset. The "monotonic" time provided by the server
would be very close to UTC (or another negotiated timescale), but its
frequency would be more stable.

I'm planning to make a demonstration of how this can improve stability
in a long chain of servers.

-- 
Miroslav Lichvar