Re: strange behaviour of ntp peerstats entries.
- From: Brian Utterback <brian.utterback@xxxxxxx>
- Date: Fri, 25 Jan 2008 13:29:38 -0500
Unruh wrote:
"David L. Mills" <mills@xxxxxxxx> writes:
You might not have noticed a couple of crucial issues in the clock filter code.
I did notice them all. Thus my caveate. However throwing away 80% of the
precious data you have seems excessive.
But it isn't really. It would be if there were no correlation between
the delay and the error, but there is a correlation. If the sampling
were completely random, then you would want to use all of the samples
to determine the correct offset, by averaging or some such method.
But since the error in the sample is correlated to the size of the
delay, using samples with greater delay and thus greater error just
increases the error of the final result, not lessens it. Since the
clocks involved also slew between samples, we want to use the newest
sample with the smallest delay.
Brian Utterback
.
- Follow-Ups:
- Re: strange behaviour of ntp peerstats entries.
- From: Unruh
- Re: strange behaviour of ntp peerstats entries.
- References:
- strange behaviour of ntp peerstats entries.
- From: Unruh
- Re: strange behaviour of ntp peerstats entries.
- From: root
- Re: strange behaviour of ntp peerstats entries.
- From: David L. Mills
- Re: strange behaviour of ntp peerstats entries.
- From: Unruh
- strange behaviour of ntp peerstats entries.
- Prev by Date: Re: strange behaviour of ntp peerstats entries.
- Next by Date: Re: NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
- Previous by thread: Re: strange behaviour of ntp peerstats entries.
- Next by thread: Re: strange behaviour of ntp peerstats entries.
- Index(es):
Relevant Pages
|