On Wed, Mar 25, 2015 at 3:22 AM, Hal Murray <hmur...@megapathdsl.net> wrote:
> > What I don't understand is why the time offset as measured by an outside > system didn't change. ?? > NTP always and continuously measures the round trip time over the network and assumes the one-way time is 1/2 the round trip time. Reducing the latency reduces the round trip time that NTP has to compensate for. So if NTP always compensates for network delay why do you get improved performance with less delay? That is because what messes up NTP is uncertainly in the delay and likely it's the case that reducing the delay also reduces the standard deviation of the delay. The other thing the messes up NTP is its assumption that the delay is symmetric (that the one-way delay = one half the round trip delay) I think reducing the round trip time also reduces error in this assumption. NTP is not magic and uses the same algorithm you would use if you lived 200 years ago and were told to synchronize two grandfather clocks in two houses that were 1 mile apart and you have to walk between the two houses and you had no third clack you could cary. What is the optimal solution to this problem: I think your first step would be to walk the distance many times to build up a statistical database for travel times to get a solid mean and sigma. Then you would walk back and forth, 24x7 and try to compute the differed in rates of the two clocks and adjust the pendulum of your clock. Setting the absolute time would not work to converge the error to zero setting the rate would. Of course the best thing would be to buy small clock you could take with you but NTP was designed to run on a "dump" network that only moves data without timing it. -- Chris Albertson Redondo Beach, California _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.