NTPD unable to adjust local clock

[Matthew Dillon]

:
:On Wed, Apr 06, 2005 at 10:36:23AM -0700, Matthew Dillon wrote:
:>     First, we have to do away with ntpd's code that tries to take the
:>     average from multiple time sources.  What a disaster that is!  At
:>     the very *best* we can have a heuristic based on the offsets from
:>     each source to try to correct the offsets, but otherwise we have to
:>     choose the best time source (lowest standard deviation at the lowest
:>     stratum) and stick with it.  None of this averaging between sources
:>     business.  Each time source has to be independantly tracked and we
:>     pick the best one, period.
:
:Just to get the fact right, it does *not* average the time sources, it
:uses the median of all good peers. Using the stratum doesn't make much sense,
:because e.g. all major German time servers are stratum 2 or greater, even
:if they have a Caesium watch at the same institute to synchronise too or a
:long wave reciever for the "official" time signal. You don't know which
:the *current* best source is, but you can try to choose a good source. That's
:done. I'll have to dig into xntp, but I'd be surprised if it did something else.
:
:Joerg

    It seems to average something.

        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.

    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.

    You are still going to (almost universally) use the time source with the
    lowest-stratum.  Otherwise time sources configured as backups will not
    work properly.  ntpd doesn't source the time protocol so it doesn't have
    to worry about loops, but if you look at xntpd you will see that it does
    in fact choose the time source with the lowest stratum (assuming it has
    synched up to that time source).  It might choose a higher stratum
    source temporarily if the lower stratum source hasn't synchronized yet,
    but that's strictly a short term condition.

    For the openbsd ntpd, since it only sinks the timed protocol and does
    not source it, you could use a running standard deviation of the round
    trip time to fudge the stratum calculation... e.g. if the stddev is too
    large you could add one to the effective stratum of that source and
    thus potentially choose a higher-stratum time source as being more
    reliable.  That might be reasonable in that specific case.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>