David Woolley wrote: > Hal Murray wrote: > >>> There is nothing per se that makes this system impossible to deliver >>> 1ms. Of course it depends of where those clients are-- if they are at >>> the bottom >>> of the sea communicating with 1bd/sec ultralow frequency radio, you will >>> not get 1ms precision. >> >> >> What's wrong with a (very) slow link? As long as there aren't any >> queueing delays, the delay should be symmetric in both directions >> and I'd expect ntpd to work OK. > > > A one baud link would have an uncertainty of a second in the time, > unless the transmit time stamps were synchronised with the signalling > units. It would also have a delay that was on the limits of causing > rejection for a normal NTP implementation. > > A 1 bit/second link would definitely have an unacceptable delay. > > A 1 baud/second link would have a continually varying latency, and, > unless the bits per signalling unit varied to compensate, a continually > varying delay. I don't think baud/second was the intended unit. I > suspect he was suggesting a 1 bit per signalling unit, 1 signalling unit > per second, case. > >> >> Does 1 bd/sec overflow some of ntpd's assumptions? Would it need >> some minpoll tweaking? >> >> Or maybe I should ask: How slow a link is still useful? >>
DCF77 for example is a "1 bit/s" transmission, a sentence taking 60s. It seems to not have issues with ms syncing. / bits/second and Baud can be a bit mushy: DCF can be viewed as a ternary code ( short, long, none ) / uwe _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
