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

Alby VA albyva at empire.org
Fri Mar 23 15:01:22 UTC 2012

On Mar 23, 9:49 am, Karel Sandler <sand... at ujf.cas.cz> wrote:
> On Fri, 23 Mar 2012, unruh wrote:
> > On 2012-03-22, Karel Sandler <sand... 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
> 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.
> Karel Sandler


 How much is that GPS170PCI card?

More information about the questions mailing list