# [time-nuts] Comparing the BeagleBone Black & Raspberry Pi asNTP servers

Chris Albertson albertson.chris at gmail.com
Wed Mar 25 12:46:05 EDT 2015

```On Wed, Mar 25, 2015 at 3:22 AM, Hal Murray <hmurray at 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
```