David Woolley <[email protected]> writes: >[email protected] wrote:
>> This algorithm is robust because it is based on >> special techniques (it uses common packets in the traces to provide >> synchronisation). >In the end, any such algorithm is going to have to use techniques >similar to ntpd or chrony's. The one advantage is that it is >retrospective, and therefore probably better matches chrony's linear >regression approach. (NTP uses a low memory, incremental algorithm.) That is why ntp has a VSZ of 4460 vs 2189 for chrony and RSS of 940 vs 748 for chrony:-) >A better example of this sort of problem, for this newsgroup, is >probably that of deriving UTC from historical information on the >individual clocks that contribute to UTC. But he also does not realise that the unconstrained computer clock would soon be out by seconds (in a day) minutes, or even hours. >I've also done this sort of thing on data with rather larger jitters and >the main error due to sloppy eyeball and wristwatch time setting >(performed at not well controlled times) on specialist (although rather >common) equipment, that doesn't support NTP. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
