How NTP works

[Hal Murray]

[was Re: Request for code & logic review]

dfoxfranke at gmail.com said:
> For starters, we have our four timestamps:
> t_1, the origin timestamp, is the time according to the client at which the
> request was sent. t_2, the transmit timestamp, is the time according to the
> server at which the request was received. t_3, the receive timestamp, is the
> time according to the server at which the reply was sent. t_4, the
> destination timestamp, is the time according to the client at which the
> reply was received. 

(and more)

I think that transmit and receive in the above are swapped.

In this context, receive and transmit refer to the server while origin and 
destination refer to the client.

There really should be someplace where this is explained clearly so we can 
refer to it at times like this and put all our effort into making thatplace 
better rather than spreading good ideas all over the place where they are 
hard to find.  Does anybody know of such a place?   If not, we should make 
one.  I'll volunteer to make a first pass.


esr at thyrsus.com said:
> I'm confused about what "the time according to the client at which the reply
> was received" is doing in the packet at all.  Surely the server can't have
> put it there, unless it can see into the future. 

There is confusion because the calculations use 4 time stamps and there are 4 
time stamps in the packet.  Only the last 3 time stamps from the packet are 
used for the calculations.  The 4th is the destination (aka arrival back at 
the client) time stamp.


dfoxfranke at gmail.com said:
> The reference timestamp isn't really used for anything, and the destination
> timestamp obviously can't be part of the packet. 

I think it would help people understand things if we included the reason for 
the the extra time stamp in the packet.  Mills wouldn't have wasted 8 whole 
bytes without a good one.


Another chunk that should go in this area:

If you look at the raw data, there are 3 unknowns:
  transit time client to server
  transit time server to client
  clock offset
but there are only two equations, so you can't solve it.

NTP gets a 3rd equation by assuming the transit times are equal.  That lets 
it solve for the clock offset.

If you assume that both clocks are accurate which is reasonable if you have 
GPS at both ends, then you can easily solve for the transit times in each 
direction.


-- 
These are my opinions.  I hate spam.