# [ntp:questions] Re: Does NTP model clock skew?

Kevin MacLeod kevin-usenet at horizon.com
Sun Feb 13 03:37:01 UTC 2005

Affan <affanahmed at gmail.com> wrote:
> I am trying to currently understand exactly how does NTP cater for
> clock skewing at individual nodes in the network. From my current
> understanding, it does so based on just statistical measurments of
> many,many offset calculations made through a two way exchange between
> the NTP server (another question.. are the server and client supposed
> to be on the same network i.e. one hop away?)- and it changes something
> in oscillator PLL. But it doesnt do anything like what e.g. RBS does -
> meaining that it does not form a line which can be used to say.. yes
> this is a value of skew that i have (based on some line drawn to best
> fit the datapoints).
>
> I hope this isnt a wrong place to ask the question, and I hope I have
> provided sufficient information so that some one can give me a
> response.

Just to be clear, let me define "clock skew":
clock skew is the difference in clock signal arrival times caused
by different transmission paths.

NTP doesn't "cater to" clock skew, it tries to eliminate it!

This is because it takes round-trip time measurements and tries to correct
for the propagation delay.  (By assuming it's equal in both directions.)

It's like the story of the old fellow who winds up the clock at his farm
and then walks to town for some shopping.  Assuming that:
- His clock read 9:00 when he left
- It was 12:00 (according to the clock in the town square) when he
arrived at town.
- It was 2:00 when he left town
- His clock showed 1:00 when he arrived home.

What time should he set his clock to?

The answer is 3:00.  Even though the clock at home doesn't know what
time it is, it could still note that he spent 4 hours away from home.
If he spent 2 hours in town, that's 2 hours travelling.  Assuming equal
speed in each direction, he arrived home 1 hour after leaving town.

Of course, if there's a hill, or he was carrying a lot of stuff in one
direction, he may be off a bit.  If you don't know anything about how
long it took to travel each direction, all you can say is that the
time he arrived home is somewhere between 2:00 and 4:00.

As for distance between server and client... it can be anything.
If they're on the same network, it works better, but they can be
across an ocean from each other.

As for comparison with RBS... what it RBS?  Google gives me:
- Royal Bank of Scotland
- Research for Better Schools
- Royal Blind Society
- Rede Brasil Sul de Comunicação
- Royal British Society of Sculptors
- Regionalverkehr Bern-Solothurn
- Rutherford Backscattering Spectrometry
- Regional Bus Stuttgart
- Rug Book Shop

ah... found it.  Reference Broadcast Synchronization.  A system
and then compare their timestamps to find their clock offsets.

A nice trick if you have such a network, but you need at least three
nodes on the network (one to send the broadcast so two can receive it
for comparison), and you need the network to support broadcasts.

Further, you need a network without unbalanced transmission times.
Suppose I have three nodes on a 100baseFX ethernet, two next to each
other and the third connected via 40 km of single-mode fiber.

Any brodcast will reach the third node 133 us (times the refractive
index of the fiber, whatever that is) later than it reaches the first
two.  You may also insert varying numbers of of bridges and
store-and-forward switches.

NTP is designed to work over any channel that will carry UDP packets.