[ntp:questions] Re: IEEE 1588 support in NTP?
David L. Mills
mills at udel.edu
Mon Oct 31 03:12:56 UTC 2005
I don't think 1588 makes a lot of sense over UDP unless the NIC has a
TSU built in. The net (pardon the pun) result is very much like the old
line discipline/streams gadget we used to use on serial lines when the
Sun IPC driver stack had jitter over 23 ms. It's easy to timestamp on
the way in as you describe. The hard part is to timestamp on the way
out; the driver needs a feature where NTP or whatever can ask for the
identifier and timestmap of the packet just sent. The sneaky way to do
this is for the driver to copy this information in the header of the
next packet received.
I don't see serious problems with jitter; algorithms like the NTP clock
filter and/or median filter make short work of that, unless the network
has serious congestion and frequent retransmissions. I'm getting a few
microseconds jitter with a PPS signal, DCD interface and 60-s median
filter now. I would hope a gigabit Ethernet with TSU and driver could
shave that to 10-100 ns if collisions and/or buffering is minimal.
I assume the TSU counters, system timer and CPU clock are not
synchronized, so something has to be done in the application to
compensate for the expected frequency errors. The NTP audio drivers are
a good example of how to deal with theose issues. I just found an
expensive sound card with a 160-PPM codec frequency error, easily a
factor of two worse than any other I have tripped over. The driver
compensates for frequency error by stuffing/deleting sample as
necessary. Even this has jitter limitation in the 100-us range.
So, where can I buy a NIC with a TSU?
Martin Burnicki wrote:
> Bjorn Gabrielsson wrote:
>>Martin Burnicki <martin.burnicki at meinberg.de> writes:
>>>Please keep in mind that PTP yields an accuracy in the nanosecond range
>>>*only* if special network adapters with PTP support are used on all PTP
>>>PTP support for network adapters means that the adapters include a
>>>hardware timestamp unit which takes a time stamp whenever a PTP packet
>>>goes on the wire or is coming in from the wire.
>>Are 1588 going into general ethernet chipsets?
> Yes. IEEE1588 uses standard UDP multicast packets, so it can basically be run
> using any ethernet NIC.
> Here is a short summary on the 3 ways to assign timestamps to specific
> outgoing and incoming network packets:
> 1.) Inside the application, if a packet is sent or received. This is very
> portable since it runs completely in user space, and this is the way
> currently used by NTP. You can also run this on operating systems where you
> don't have access to the source code of the NIC drivers. However, this is the
> most inaccurate way since the time stamps depend on the latency of the IP
> stack, and on network collisions.
> 2.) Inside the NIC driver, e.g. in the interrupt service routine. This avoids
> the latencies of the IP stack, but you must modify the source code of the
> driver, or have a driver which takes time stamps if certain packets are being
> sent or received. Also, you don't know the latency due to network collisions
> when sending packets.
> 3.) By the NIC hardware. You need a time stamp unit (TSU) which listens on the
> data lines between the MAC and the PHY. The TSU contains a pattern matching
> unit which detects the pattern of the desired packet type in the serial bit
> stream on those data lines. If such a pattern is detected then the pattern
> matching unit must capture a time stamp of a high speed counter which is also
> part of the TSU. Since this method takes time stamps when a packet goes on
> the wire or arrives on the wire is also capable to eliminate the latency due
> to network collisions.
> The driver must be able to read those time stamps from the TSU and either
> assign them to the packets or pass them up the protocol stack to the
> application which then assigns the time stamps to the packets.
> The TSU can be implemented in a programmable logic device like an ASIC or
> This method is the most accurate, but it requires a NIC with a TSU, and a
> kernel driver which supports the TSU.
> The problem here is that most commonly used NICs have the MAC and the PHY in a
> single chip, and the data lines on which the TSU must listen is not
> accessible outside the chip.
> You must also be aware that the timing accuracy is significantly degraded if
> the PTP packets go through switches or routers which don't have a special
> handling for such packets, so packets may be queued which introduces again an
> unknown latency.
> An overview of the principles of PTP and the way it uses hardware packet
> timestamping can be found here:
> Best regards,
More information about the questions