Request for code & logic review

Eric S. Raymond esr at thyrsus.com
Fri Nov 25 01:21:46 UTC 2016


Daniel Franke <dfoxfranke at gmail.com>:
> 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.

Er...

> t_2, the transmit timestamp, is the time according to the server at
> which the request was received.

The "transmit timestamp" is a receipt time?  Are you sure that's right

>From the protocol diagram:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     Reference Timestamp (64)                  +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Origin Timestamp (64)                    +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Receive Timestamp (64)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                      Transmit Timestamp (64)                  +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Your t_1 looks like it must be the second field, "Origin Timestamp"

Your t_2 looks like it must be the fourth field, "Transmit Timestamp"

Your t_3 looks like it must be the third field, "Receive Timestamp"

Is t_4 field 1 (the "Reference Timestamp") your "destination timestamp"?

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.

> Lambda nominally represents the maximum amount by which theta could be
> off. It's computed as delta/2 + epsilon. The delta/2 term usually
> dominates and represents the maximum amount by which network asymmetry
> could be throwing off the calculation. Epsilon is the sum of three
> other sources of error:
> 
> rho_r: the (im)precision field from response packet, representing the
> server's inherent error in clock measurement.
> rho_s: the client's own (im)precision.
> PHI*(t_4-t_1): The amount by which the client's clock may plausibly
> have drifted while the packet was in flight. PHI is taken to be a
> constant of 15ppm.

The big formula in the C comment looks like a botched attempt to compute
this, under the assumption that ntpdig doesn't have rho_s available and
must set it to zero.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


More information about the devel mailing list