[ntp:questions] why is this clock not even considered?

David Woolley david at ex.djwhome.demon.co.uk.invalid
Fri Dec 28 08:21:55 UTC 2007


In article <fkv165$d6c$1 at scrotar.nss.udel.edu>,
David L. Mills <mills at udel.edu> wrote:

> documentation. The probable cause is dispersion too high or the noselect 
> option is present. The prefer option has nothing to do with this.

I would have thought the most likely cause was dispersion too *small* not
too large, causing the SHM time to fall outside the majority cluster. 
Clock drivers don't get a very large allowance for reading error, so,
on a machine with the good precision, typical of modern machines, they
need to be accurate to much better than the 5 to 10ms seen here. 

A contributory factor may be that the the same issue is causing the
the reading error in the current selected system peer being underreported
thus meaning that only times within a few hundred microseconds are 
acceptable.  Many DCF clocks don't have that sort of reading accuracy.
It's also not particularly difficult to exceed that sort of tolerance
simply by the one way trip time from DCF to the receiver.

I think that modern clock precisions really need the addition of an error
tolerance parameter for clock drivers  (which should be default to around
800ms for the local clock driver!).

In this case, given current configurability, one wants to trim out the 
systematic error in the SHM clock and also consider excluding the LAN
based DCF source, if there is any doubt that its systematic error may not
have been corrected.




More information about the questions mailing list