How NTP works

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> [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.

Daniel corrected that in his next reply.  

> 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.

For right now I need this explanation to live in the header comment of
packet.py; it has to be there to explain the theta/delta/epsilon
formulas in the SyncPacket class, which is crucial to implementing
Python ntpdig, and will be the core of ntpshark as well.

Once we get it all polished up it can move to docs/, but I weant to keep
the content issues separate from the organization/location issue while
we get it right.

> 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.

Oh yes indeed.  That confused the hell out of me.  In fact it's still doing so.

/me looks in the code.

That's the 'reftime' field in struct pkt.  Grepping, I find...that it really
*doesn't* seem to be used.  But verifying this is confusing because there are
other variables with reftime in their names.  You should both check me on it.

> 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.

I'll just edit this into that coment header.

OK, I've pushed the state of our knowledge.  Hal, Daniel, please review it.
The salient questions are: Is the reference timestamp used anywhere?  What
does ntpd put in it on transmission?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>