[ntp:questions] Re: IEEE 1588 support in NTP?

Martin Burnicki martin.burnicki at meinberg.de
Mon Oct 31 10:13:58 UTC 2005


Dave,

David L. Mills wrote:

> Martin,
> 
> I don't think 1588 makes a lot of sense over UDP unless the NIC has a
> TSU built in.

Agreed.

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

If the time stamp unit is capable of listening on the interconnection lines
between the PHY and the MAC of the network board, it can take timestamps on
incoming and outgoing packets in the same way, with the same accuracy.

Finding a way for a driver to get the time stamps out of the TSU and passing
it up to application is just a matter of specifications and policy. The
proble which arises is that the time stamp of an outgoing packet is only
available after the packet has already slipped onto the wire. This time
stamp is an additional piece of information which can't be sent in the
packet itself. Also, modification of the outgoing packet on the hardware
level would make crypto hashes invalid and unusable.

PTP has an elegant method of sending a second packet which contains the time
stamp of the initial outgoing packet.

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

Currently there are no TSU solutions I'm aware of for Gigabit Ethernet. The
problem is that the programmable logic devices which run at the required
speed are very expensive and power consuming.

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

In Winterthur we've had lots of discussions on this topic with Frank Kardel
who has also attended the plug-fest. 

There are different possible approaches to this, each of which naturally has
advantages and disadvantages.

Some operating systems (I think at least some *BSD versions, and upcoming
Linux kernels) have the time-of-day clock strictly separated from its time
base. Those systems could relatively simply be configured to use a TSU's
oscillator as the time base for the system clock, so NTP or PTP just had to
adjust the system time, and all time stamps taken in the TSU would be
related directly to the system time, not to a different clock domain.

[...]
> So, where can I buy a NIC with a TSU?

I'm aware of a source for PCI NICs with TSU ...


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list