Subject: Re: [ntpwg] REQUEST FOR TEXT - Protocol Doc Changes

From: "STUART VENTERS" <[email-masked]>
Date: Tue, 13 Nov 2007 15:30:20 -0600

With regards to where to put the timetag.

The simplest plan is certainly to put it at the start of the packet like 1588 etal.
  I think I still side with simple,
  but Dave's comment about how things happen in the kernel made me think of the following:

A S/W implementation doesn't have a single place to put the timetag.
   For Transmit, the tag might be just a bit before the first bit.
   For Receive, it might be a bit after the last bit.
   Assuming the packet times are the same in both directions,
     these differences cancel out just like link delay.

I thought this was a bug due to what was possible from the constraints of NIC's and kernels,
   but it may actually be a feature if the server and client are connected to a switch via different speed links.

Assuming the following:
	1) a switch forwards after receiving a whole packet,
	2) the server is connected with a fast link
	3) the client is connected with a slow link

Then with the timetag at the start,
   the client to server delay is processing time plus a few bit times plus a packet time on the slow link,
   the reverse direction is similar except with a packet time on the fast link.

This causes a violation of the symmetric delay requirement and gives the client a time offset.
With the timetag like the S/W, it looks like the offset goes away.

Note that changing the number of header bytes is another way to change the effective link speeds.

Hopefully, I'm not drawing my time lines correctly?

Cheers,

Stuart

_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Wed, 14 Nov 2007 17:38:34 +0000

Stuart,

Well, the hardware needs to recognize the SOF before striking a stamp 
and that's exactly right. It's reproducable and independent of line speed.

To clarify software timestamping, the transmit and receive timestamps 
are captured by the driver at interrupt time; that is, at the end of the 
packet. In principle this can yield accuracy as good as the SOF, but 
diluted by the interrupt latency. There are undoubtably issues with 
smart NICs that do multiple frame buffering, etc. It might even be 
possible to temporarily turn these features off with a tagged packet.

The issue is how to snarf these timestamps in a vanilla kernel 
interface. It has been suggested this could be done using socket 
options, but this might depend on the particular kernel architecture.

Understand my agenda here is not to compete with 1588, but explore the 
technical issues on getting the best time using software timestamping 
and two-step protocol. As you might see with ntpq probe of our very busy 
pogo.udel.edu and rackety.udel.edu, which generally stay within a few 
microseconds of GPS/PPS and circa 100 microseconds across the 100-Mb 
Ethernet. Software timestamping should reduce the Ethernet wiggles to 
the order of the GPS/PPS wiggles modulo switch latencies, which should 
largely be defeated by the NTP clock filter.

Dave

STUART VENTERS wrote:

> but it may actually be a feature if the server and client are 
> connected to a switch via different speed links.
>
> Assuming the following: