Re: [Ntp] Antw: [EXT] Re: An NTPv5 design sketch

[Doug Arnold <[e-mail]>]

There are use cases for this concept:

The virtual clock can be kept as a backup to some other source of time, and could take over the system clock if the other source of time went away.  That would allow the NTP servo loop to be warmed up  and experience less startup transient when it took over.

One could have several sources of time come into a device, through different mechanisms, each run its own virtual servo loop. A combining algorithm, outside of each of the mechanisms, controls the clock using information from all of the mechanisms.

A device might have a clock running on some arbitrary timescale as part of a closed system, but keep a virtual NTP clock just to log events with standard time.

Here is a crazy one, but a company actually uses it in their network.  Time is distributed by both PTP and NTP.  If the time from the two distribution mechanisms agree to within the expected error bounds, then the clock is set by PTP, which is assumed to be more accurate.  If PTP and NTP time disagree by too much, then the clock is set by NTP, which is assumed to be more robust.  Kind of embarrassing for both protocols if you ask me.

There are probably other use cases.

Doug

________________________________
From: ntp <[e-mail]> on behalf of Ulrich Windl <[e-mail]>
Sent: Tuesday, April 21, 2020 7:00 AM
To: Rich Salz <rsalz=[e-mail]>; Kyle Rose <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Daniel Franke <[e-mail]>
Subject: [Ntp] Antw: [EXT] Re: An NTPv5 design sketch

>>> Kyle Rose <[e-mail]> schrieb am 21.04.2020 um 15:51 in Nachricht
<25459_1587477108_5E9EFA73_25459_2_31_CAJU8_nUXUEtsddE9byQgEfMknLSz8ywMs23CNyYKF
[e-mail]>:
> On Tue, Apr 21, 2020 at 9:35 AM Salz, Rich <rsalz=
> [e-mail]> wrote:
>
>>
>> >    The device may be very simple. It may not have an OS and NTP may be
>>     the only networking it does. It could be measuring intervals in a
>>     physics experiment, or controlling a robot in a factory.
>>
>> I would like to see this use-case *not* be a requirement for NTPv5.
>>
>
> Strong agree, but because NTP's purpose is to synchronize wallclock time
> first. Intervals are a second-class citizen, and anyway conflict with the
> first requirement once you get beyond very short intervals.

An interesting concept would be a "virtually corrected (software) clock" that leaves the OS clock alone, keeping the offset and drift als variable. So at any time the OS clock could be "fixed" from the virtual clock as if it were continuously adjusted all the time. Eventually this would allow to run multiple versions of NTP on a single host ;-)


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