[ntp:questions] Any chance of getting bugs 2164 and 1577 moving?
sandler at ujf.cas.cz
Fri Mar 23 13:49:21 UTC 2012
On Fri, 23 Mar 2012, unruh wrote:
> 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
>> Measurement of these delays is described in some articles listed in
> 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?
I did not participate in these measurements and I can not comment on their
methodology. High delays correspond to measurements at high load, but it
seems that the lower limit is not negligible. Especially compared to
offset fluctuations, which can be an order of magnitude smaller.
On my site I can watch more than half a dozen stratum-1 servers with
delays below 2ms. All show each other more or less stable differences that
probably can not be entirely attributed to asymmetries of the network.
Our stratum-1 server uses GPS170PCI card with its own clock and a number
of useable outputs. One option is to use the PPS output (accuracy garanted
better than 250ns) connected to the DCD pin of the serial port.
Fluctuations of the offset were below 2us with occasional blips. Now I use
another option. Blips are gone, offsets fluctuate just below 1us standard
deviatiation and, to my surprise, new option shifted the offset by 32us.
System driven by PPS had time delay. Unfortunately the resolution of
SHM refclock is limited to 1us, but that is another matter.
In any case, the relationship of the system time to UTC and calibration of
stratum-1 server is an interesting problem.
More information about the questions