[was Re: Request for code & logic review] [email protected] 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. [email protected] 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. [email protected] 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. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
