Re: NTPD unable to adjust local clock

[Miguel Filipe <miguel.filipe@xxxxxxxxx>]

Hi there, in the middle of this imense and juicy talk, anyone talked
with the maintainers, so that OpenNTPd could be correctws upstream,
were it should, instead of burdening DragonFly team.
Or at least, all bugs/fixes should be pushed upstream.


I vote for ntpd because 1, 2 second diferences between my servers
makes no problem.
I think kerberos and IDS's can tolerate that.

On Apr 7, 2005 9:46 AM, Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> :
> :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@xxxxxxxxxxxxx>
> 


-- 
Miguel Sousa Filipe