Re: NTPD unable to adjust local clock

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Thu, Apr 07, 2005 at 01:46:14AM -0700, Matthew Dillon wrote:
>         qsort(peers, offset_cnt, sizeof(struct ntp_peer *), offset_compare);
>  
>         if (offset_cnt > 0) {
>                 if (offset_cnt > 1 && offset_cnt % 2 == 0) {
>                         offset_median =
>                             (peers[offset_cnt / 2 - 1]->update.offset +
>                             peers[offset_cnt / 2]->update.offset) / 2;
>                         conf->status.rootdelay =
>                             (peers[offset_cnt / 2 - 1]->update.delay +
>                             peers[offset_cnt / 2]->update.delay) / 2;
>                         conf->status.stratum = MAX(
>                             peers[offset_cnt / 2 - 1]->update.status.stratum,
> 			    peers[offset_cnt / 2]->update.status.stratum);
> 		...
> 
>     That looks pretty bad to me.  I don't know what they think they are
>     doing there.

That's the statistical computation of the median of an even number of values.

>     I'm not sure what you mean by not using the stratum ... it doesn't matter
>     WHAT the stratum of all major German time servers are.  It just matters
>     what the lowest one the time daemon sees.

The stratum is there to prevent loops, my point is that it doesn't
necessarily offer any quality guide line.

ntpd does implement a NTP server, it uses the highest stratum of the
upstream server incremented by one.

Even the round trip time doesn't indicate a good time source, what matters
is the standard deviation (as you said).

Just as an example, 134.99.176.3 is a stratum 3 server in de.pool.ntp.org,
as 81.169.155.234 is. The first has a relative offset of 0.6 seconds to all
other de.pool.ntp.org server, you can't detect that if you base the decision
on the stratum of a single server. You have to do some kind of weighted
decision.

I'm running xntp now, so far it is not much more stable. I have a local
patch in my tree to correct the offset calculation and some other minor
things, but given that the difference even of the de.pool.ntp.org is in the
area of +-10ms, I'm not sure if you can even achieve a much higher precision.
One way to reduce the effect of clock drift is of course to reduce the probe
interval, which is in the area of 40 minutes after the initial syncs here.
I'm still evaluating the problem though.

Joerg

Joerg