Re: PSA: Clock drift and pkgin

On 2023-12-21 14:15, Jan-Benedict Glaw wrote:
> On Thu, 2023-12-21 13:58:21 +0100, Johnny Billquist <[email protected]> wrote:
>> On 2023-12-21 13:53, Jan-Benedict Glaw wrote:
>>> On Thu, 2023-12-21 12:49:06 +0100, Johnny Billquist <[email protected]> wrote:
>>>> On 2023-12-21 12:14, Jan-Benedict Glaw wrote:
>>>>> Looking at the numbers, I wonder about multiple issues here. Why did
>>>>> the jitter values rise up that much, while the delay keeps its value?
>>>>
>>>> Unless I remember wrong, delay is merely how long it takes for packets to
>>>> travel back and forth to the ntp server. So it has no relation to jitter or
>>>> offset. It would rather be weird if delay suddenly started changing.
>>>
>>> delay is ... "ping time".  jitter is a measure of how much ping times
>>> differ to each other.
>>
>> Right for delay. But no for jitter. Jitter is, unless I remember wrong,
>> comparison between your local clock and the server clock, and how much they
>> are shifting around compared to each other. It has nothing to do with ping
>> times.
>>
>> And jitter have to get low for ntp to start syncing, since it's not possible
>> to do any kind of syncing if local time is moving around too much compared
>> to server time. It becomes impossible to tell how local time should be
>> modified in such a case.
> 
> Referring to https://kb.meinbergglobal.com/kb/time_sync/ntp/ntp_basics
> ("Checking ntpd's Time Adjustment Performance"), it lists:
> 
> delay	The mean packet delay, in milliseconds. This is the mean
> 	execution time required to send a read request to the time
> 	source, and receive the reply from that source.
> 
> offset	The mean time offset, in milliseconds.
> 
> jitter	The time jitter, in milliseconds. This indicates how much
> 	packet delays from individual pollings vary from the mean
> 	packet delay.

Well. I'm reading the RFCs:
https://datatracker.ietf.org/doc/html/rfc1305
https://datatracker.ietf.org/doc/html/rfc5905


There is too much to just quote everything, but 5905, which is for 
NTPv4, says:

The jitter (psi) is defined as the root-mean-square (RMS) average of the 
most recent offset differences, and it represents the nominal error in 
estimating the offset.


And about offset, it says:

The offset (theta) represents the maximum-likelihood time offset of the 
server clock relative to the system clock.


So basically, offset is the difference between server clock and your 
local clock.

Now, network jitter can be a contributing factor, but it's not the 
definition, or the full part of what jitter is.

Of course, I could have been misunderstanding it all, but anyway...

> But to tell for sure, we'd have to dive in into ntpd's code to prepare
> `ntpq`'s `peers` data.

Sure. But the fact that you noted that the jitter was behaving in a way 
that did not match with your expectations, based on what your 
understanding of what jitter is might be suggesting that there is a 
mismatch here.

But in the end, the fact still remains that we have lousy time keeping 
on the VAX, and ntp is not able to cope with it. So let's try to fix this.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol