[ntp:questions] Any chance of getting bugs 2164 and 1577 moving?
sandler at ujf.cas.cz
Fri Mar 23 20:28:00 UTC 2012
On Fri, 23 Mar 2012, unruh wrote:
> On 2012-03-23, Karel Sandler <sandler at ujf.cas.cz> wrote:
>> 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
> And what is that "another option". How do uyou know it shifted the
> offset? What did you use as the standard. Note that as I said, measuring
> the offset on a parallel port I got at most 2us.
> I would be surprised if the serial port were that much worse.
>> 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.
> Agreed. And measurements, not theory , are needed.
Now I use SHM refclock. Any difference between GPS clock and system time
is read and passed using Meinberg daemon.
The value of the shift was verified in two ways. Three nearest stratum-1
servers have jitter below 30us. One day floating average of their offsets
now lies between zero and 3us. Move by 30us was quite distinct. Moreover,
the card enable the use of three refclocks simultaneously. Differences
between PARSE, PPS and SHM refclocks were stable and clearly visible.
If time permits, I'll try the parallel port.
More information about the questions