[ntpwg] Documents, slides, etc. from WG meeting

[Martin Burnicki]

Dave,

David L. Mills wrote:
> Martin,
>
> Yes, I am familiar with the distinction between boundary clocks that do
> or do not involve a control loop. Of course, NTP has the same
> distiction; however, the NTP control loop has a carefully defined
> transfer function that minimized the whip effect of cascaded control
> loops. 1588 could do the same thing, but most would consider that
> outside the scope of the specification. A 1588 bis could present such a
> specification.

Indeed. However, while there is a single implementation of NTP which us widely 
used, there are several implementations of the PTP protocol stack and the 
algorithms and control loop characteristics used.

> One thing that may have escaped mention is that 1588 synchronizes the
> NIC drivers in the network, not necessarily the computer system clock.
> This adds another control loop to the impulse response. The time purist
> might use NTP at the edges of a private network, then distribute the
> local offset of the NIC relative to the NTP time to all other hosts
> which would then run the same discipline (NTP or kernel) for the local
> system clock. So,all hosts with have the same control loop dynamics and
> very small wiggles with respec to each other.
>
> That bit of protocol wizardry could be incorporated in 1588 bis.

I think you have to distinguish even more. 

As I understand it the original target for NTP were computers which have a 
more or less good or bad chrystal built in, and also provide a more or less 
good implementation of the system clock. So NTP has to deal with the existing 
hardware and try to get the best results under the given conditions.

Also as I understand it, the target of PTP/IEEE1588 explicitely includes 
embedded devices, so usage of PTP for time synchronization with distributed 
instruments is part of the LXI (LAN eXtensions for Instrumentation) standard, 
the LAN-based successor to GPIB. See also
http://www.lxistandard.org/home

As opposed to a standard computer, the manufacturer of an embedded device has 
full control over the hardware, so he can provide a single oscillator of the 
quality he needs, and use that oscillator both to implement the system clock, 
and to timestamp incoming and outgoing network packets. So there is only a 
single control loop to have PTP adjust the system time.

With a standard computer things are quite different. The built-in clock is in 
most cases based on a cheap chrystal, and the NIC chips which are often on 
the mainboard nowadays don't provide a way to timestamp network packets by 
hardware. So if you want to do hardware timestamping you have to install an 
additional NIC which provides in most cases its own oscillator.

So there are several possibilities, which are basically the same for both NTP 
and PTP. Here are some thoughts:

- If you have a single NIC with its own oscillator, e.g. on a PCI card, then 
you have two different timekeepers in the system. Normally the clock based on 
the cheap chrystal is "known" by the operating system and thus controllable 
via the system API calls. It also provides the time reported to the 
applications running on that system.

The oscillator on the NIC board is something special, and you need a way to 
relate both time scales to each other, which requires an additional control 
loop. There are basically 2 ways to synchronize those 2 timekeepers: the time 
synchronization daemon (either NTP or PTP) could discipline the oscillator on 
the NIC, and the additional control loop disciplines the OS system clock, or 
vice-versa. I bet the first option yields better results than the second.

- If the operating system provided an abstraction layer for the system clock 
which could "point" to any oscillator/counter chain then the adjtime() and 
gettime() system calls could be redirected to use the better oscillator on 
the NIC PCI card instead of the built-in cheap chrystal. This would make the 
additional control loop obsolete.

- However, if you install 2 or more timestamping NIC cards in the same system 
in order to support several subnets the the original problem is back. Unless 
there's a way to synchronize the oscillators and counter chains by hardware 
(or use the oscillator of the first NIC also for the other NICs, you must 
again relate the different clock domains of the individual NICs to each 
other. 

- Anyway, you need a way for the time synchronization daemon to read the 
current time/counter of a NIC pretty fast. E.g. if the NIC is a USB device 
which supports hardware timestamping it's no problem if you read the 
timestamps with a millisecond delay. The problem arises if you want to read 
the current time counter value in a fast way in order to relate it to the 
system time, in which case the USB latency will yield some error.

We have already discussed the aspects above with Frank Kardel some time ago, 
so I'll CC: this email to Frank.

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany