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

[Doug Arnold <[e-mail]>]

Regarding the datatypes:  What do you think of time16, time32, and timestamp64.  It makes a distinction between the first and the format used for timestamps.

Regarding the correction field: I think that the easiest route to adoption by manufacturers of switches and routers is to make it work just like PTP.  That is one field that corresponds to the dwell time, difference between the egress and ingress timestamps.  In my scheme the switches and routers do not even have to determine if the message is a request or a response.

Regarding interleaved mode:  I think that this is only important for niche applications that need high precision.  These are generally in smaller networks, where servers saving state for each client is less of an issue.  Note also that several manufacturers make ntp servers with one-step hardware timestamping, where neither follow_up messages not interleaved mode are needed.

Doug

On 11/26/20, 6:04 AM, "ntp on behalf of Miroslav Lichvar" <[e-mail] on behalf of [e-mail]> wrote:

    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

    _______________________________________________
    ntp mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/ntp