Martin Burnicki wrote: > David Woolley wrote: > Basically I agree. However, if the packet turnaround time is low, e.g below > 1 millisecond on a local net, and evaluation of the timestamps yields an > offset of about 120 ms (according to my example shortly after startup) then > the result clearly indicates the own system time is off by 120 ms.
You need to use the full error bound calculation, not just single hop delay. I.E. you need to account for root dispersion (contributions from clock drift since the last measurement, precision, etc.) and root delay. You also need to account for the server being in its initial convergence period (I think ntpd currently converges root dispersion faster than it actually converges the time! > > Of course if you rely to some internet servers then there may be rather > large turnaround times/delays. However, given the upstream server sends > correct time stamps then then the error due to packet delays on the network > can not exceed the packet turnaround interval. So if the turnaround But that isn't the only source of errors. > interval is low (e.g. < 1 ms) and the time offset is high (e.g. ~120 ms) > then ntpd should indeed start compensate the time offset much quicklier > than it currently does. > > > If a complete network is powered up, inclusive of the time server, and the > initial time offset of the time server is 120 ms and is only slewed down > after hours, do you really thing it's better to slew the time that slowly > on the time server and providing a time to his clients which is 120 ms off? Dave Mills normally argues that the loop constants are carefully crafted so that when you chain many hops together, you still have a system that is stable. I was anticipating that argument by providing an escape clause. > > So the clients would start to synchronize to a reference time which is off > by 120 ms and then follow the slow corrections of the time server? > > _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
