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

unruh unruh at invalid.ca
Fri Mar 23 21:04:56 UTC 2012

On 2012-03-23, Karel Sandler <sandler at ujf.cas.cz> wrote:
> 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
>>>>> 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?
>>> 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.

But how is the time gotten into the shm. You still need some daemon to
wait for the pulse from the GPS timestamp it and then install that
timestamp into the shared memory segment. That is not necessarily either
worse of better than any other method. In all cases the crucial issue is
how fast after the pulse from the GPS hits the computer can that pulse
be timestamped with the computer's time. 

> 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.

Not sure what you mean. If those were serviced by different daemons,
then, an interupt shuts off other interrupts, and each daemon would have
to wait for the previous one to finish before starting up itself. Ie,
what you could be seeing is simply that the new one is first in the
chain and is thus grabbing the interrupt first. 

> If time permits, I'll try the parallel port.
> Karel Sandler

More information about the questions mailing list