[ntp:questions] Re: IEEE 1588 support in NTP?
martin.burnicki at meinberg.de
Tue Nov 1 09:38:29 UTC 2005
David L. Mills wrote:
> It doesn't make a lot of sense to moo time based on a herd of TSU
> counters unless each cow in the herd is wrangled to a common timescale.
Agreed. If there are several NICs with independent TSUs there must be a way
to relate the clock frequencies/counters of each TSU to each other.
On the other hand, if you have a look at a "client" machine, it may be an
easy and straightforward solution just to have a single TSU which is used
for timestamping and also as the time base for the system time-of-day
> The fastest machine I have, a Sun Blade 1500, can moo time in about 400
> nanoseconds. If each cow in the herd has a frequency error up to 100 PPM
> and the accuracy expectation is one microsecond, the moo needs to be
> adjusted on the order of 100 times each second. This requires a
> processor interrupt at intervals of 10 ms and an adjustment for each cow
> computed for convenience at intervals of one second.
This is true if you must rely on a timer hardware where you are unable to
modify the timer clock frequency directly. A TSU is a special piece of
hardware which is designed with time keeping in mind, so the hardware
developers should provide a way to modify the timer clock frequency without
having to insert or remove timer counts from inside a timer tick interrupt
For example, the GPS receivers manufactured by Meinberg have oscillators
whose output frequency can be adusted in a narrow range by an input
voltage, which comes from a digital-to-analog converter.
In order to adjust the output frequency you just have to increase or
decrease the DAC value. The advantage of this method is that the number of
output pulses does not vary with corrections, i.e. you have exactly
10000000 pulses even if you slew the frequency a bit. This is essential
especially if you use the oscillator frequency for additional purposes.
A different approach would be to use a DDS circuit where you could also
modify the clock without having to rely on a very high interrupt response
> I think you see where I am going. The infrastructure is just like
> wrangling time in a SMP system where each processor has its own cycle
> counter and where the counter can be read at any time from any
> processor. This infrastructure has been implemented in the stock kernel
> of the Digital/HP Alpha running Tru64.
Yes, I see where you're going. I'm aware of the problems due to several
clock sources, no matter whether they are several high speed timers in the
CPUs of a SMP system, or several oscillators on veveral TSUs.
However, I think the TSUs can be used to avoid latencies and retransmission
delays for network packets which increases the basic accuracy. On the other
hand, I think the same methods which are used to relate the CPU timers in a
SMP system to each other could be used to relate the times from several TSU
oscillators to each other.
> There are lots of ways to milk the cow, but some ways may be more
> practical than others. All need to reveal the four timestamps T1-T4 in
> one form or another. Your method has the advantage of compatability, but
> hazards the overhead of preamble, header, checksum and guard time, as
> well as the possibility of collision and retransmission.
Please, if you refer to IEEE1588, that's not *my* method. I'm more
NTP-biased ;-) but I also see what the PTP folks are doing.
> In my favorite the frame format leaves space for two timestamps
> following the checksum. An outgoing timestamp is struck at the first bit
> following the preamble and transmitted twice after the checksum. An
> incoming timestamp is struck the same way and copied after the
> timestamps in the receive buffer. The timestamps are rejected if the
> first two don't match. This scheme remains accurate even if the frame is
> retransmitted and takes advantage of the inherent resistance of the NTP
> algorithms to data omission.
> A disadvantage with either method is that the useful capability in the
> stock NTP algorithm to detect replayed and spoofed packets is
> diminished, depending on how the driver timestamps are revealed to the
> core algorithms.
Yes, that's also my objection.
More information about the questions