On Wed, 25 Mar 1998, Jonathan Stone wrote:

> I've just committed a definition of TIOCDCDTIMESTAMP to sys/sys/ttycom.h.

>Wouldn't another option be to either put the serial chip in loopback mode
>(available in the 8530 SCC) or make a loopback plug, and then run the port
>at 10 baud? It'd be easy to keep the transmit queue full :-) and there'd
>be no dropped pulses. Even if interrupt problems keep things constapated
>for a while (delay character reception), none of the characters would get
>dropped.

Hi Bill,

This feature is for NTP time-vultures with GPS or atomic reference
clocks, who want to measure the phase difference between their CPU
"real-time" clock and their reference clock as tightly as possible.

The reference clock emits one  pulse  per second (PPS), on the second.

For TIOCDCDTIMESTAMP, that pulse is wired to a UART carrier-detect lead.
The kernel takes an interrupt on the PPS , and samples the CPU's idea
of the clock in the UART modem-status-change interrupt handler.
This gives you the phase error, plus the interrupt latency.
That's good to within ten microseconds on a modern x86.

The true timehead will measure the interrupt latency (from the PPS
pulse edge to the software strobing some acknowledgement, as it reads
the clock chip), and configure that latency into NTP with a fudge-factor.

For this application, getting low but above all *constant* latency for
the interrupt is paramount. Using the serial port for data is
irrelevant.  It's not used for data at all, or typically used for a
very low data-rate application (like reading NMEA timestamps, about 10
bytes) from a GPS device.

The altenrative is to use a parallel port and hook the PPS interrupt
signal to a parallel line that will generate an interrupt.  I'd like
to support that too: it could have marginally lower jitter
(variance in latency).

Hope that clears things up.

--Jonathan