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

[Ulrich Windl <[e-mail]>]

As I just had pressed "reply", only Doug  got the response. Please see it attached. Sorry.

>>> Doug Arnold <[e-mail]> schrieb am 21.04.2020 um 20:14 in
Nachricht
<[e-mail]>

> There are use cases for this concept:

--- Begin Message ---

>>> Doug Arnold <[e-mail]> schrieb am 21.04.2020 um 20:14
in
Nachricht
<[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.

What does the current NTP implementation do if you have two stratum-1 sources
disagreeing on the correct time while being of "high quality"? Toss a coin?
Officially it does not, but the results are quite similar. It's named "clock
hopping". "prefer" isn't really a solution if you have no control over such
(stratum-1) sources...

> 
> There are probably other use cases.
> 
> Doug
> 
> ________________________________
> From: ntp <ntp‑[e-mail]> on behalf of Ulrich Windl 
> <[e-mail]‑regensburg.de>
> 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_nUXUEtsddE9byQgEfMknLSz8ywMs23CNy
> YKF
> [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 

--- End Message ---