G.W. Haywood wrote: > Hi there, > > On Fri, 7 Sep 2012, ntp at jama dot is wrote: > > recently I setup ntp.jama.is ntp server. It uses a Gude mouseCLOCK > > USB II to get the time via DCF 77. > > ... > > I am wondering why my DCF77 clock is rate as the bad time > > source. can anyone shed some light on this or help me to analyze > > this issue. > > If you are in Iceland you are well over 2,000km from Frankfurt. > > Over that distance the line of sight propagation delay alone would be > in the region of seven milliseconds. Of course your signal path will > not be along a line of sight. Reception will suffer from atmospheric > effects which change the effective path length diurnally, and also > sometimes unpredictably depending on things like solar activity. > That is all inevitable with long range radio communications on Earth. > > Your USB system might also add significant processing overheads, > although I would not expect these to be large compared with those > caused by the radio wave propagation issues. I wonder if a device > which uses the EIA/TIA-232 serial interface might preform better.
All of the above is correct, and in addition the time derived from the DCF77 standard AM modulation is often not very accurate. Usually there are limited antenna and filter bandwidths to suppress electrical noise, and these filters are causing a signal delay which results in a time offset depending on the filter bandwith. One can try to fudge the refclock time such that the resulting offset for the refclock is in the range of the offsets observed for the external NTP servers, which should prevent the refclock from being overvoted by the NTP servers and thus flagged as falseticker. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
