[ntp:questions] Any chance of getting bugs 2164 and 1577 moving?

unruh unruh at invalid.ca
Fri Mar 23 00:50:25 UTC 2012

On 2012-03-22, Karel Sandler <sandler at ujf.cas.cz> wrote:
> On Thu, 22 Mar 2012, unruh wrote:
>>> In addition, it should be noted that in the case of serial PPS
>>> the system time may lag behind UTC by tens of microseconds.
>> tens of microseconds? Where does this come from? The interrupt
>> processing time is not that long.
> I took these numbers from 
> http://www.cesnet.cz/doc/techzpravy/2007/ntp-server/.
> Measurement of these delays is described in some articles listed in 
> references.

Well, if correct that is hugely different from the latency on a parallel
As I said I tested that. I wrote a driver which grabbed a timestamp,
wrote to one of the output pins of a parallel port which was connected
to the ACK pin on that parallel port. The interupt service routine which
serviced the ACK interrupt immediately timestamped the interrupt. (ie
the second instruction grabbed a timestamp. The first checked the ack
pin to make sure this was a parallel interrupt) the delay between those
two timestamps (usec precision) was 1-2us. Far from 8-50 us that they

I have not done the equivalent (Parallel port pin to serial port DCD
interrupt) but I would be very surprized if it is that much worse. 

Note that the fluctuations are not that much worse. I have run a GPS via
the serial port DCD and find offsets that fluctuate around the 1us
standard deviation (using the nanosecond timer in Linux) with occasional
excursions. While this does not measure the latency, it does measure the
fluctuations in the latency and then are less than 1us. (Note that in
the reference in the paper you quote, the fluctuations in the latency
are much large than this-- normally about 2us, but sizable tails out to

I suspect that the methodology is bad-- ie, is most of the delay in
switching on the RTS pin rather than in the interupt latency?

> Karel Sandler

More information about the questions mailing list