On 2012-03-22, Karel Sandler <sand...@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 port. 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 claim. 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 30us.) 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 _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions