Re: [chrony-users] GPS / Chrony NTP server config questions

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

On Thu, 16 Nov 2017, Denny Page wrote:

> > On Nov 16, 2017, at 10:32, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
> >
> > On Thu, 16 Nov 2017, Denny Page wrote:
> >
> > > Interrupt latency for character devices in Linux is 6-7 us, even with no other activity. You
> >
> > It has been a while but I ran tests on a system in which I changed the state
> > of a parallel port pin and fed that into an interrupt grabbing the system time
> > just before toggling the pin, and the time when the interrupt service routine
> > got the interrupt. The latency was of the
> > order of 1us, not 7. Now that was on an older machine with the 1us, not the ns
> > clock. I have not tried this recently but would be surprized if the time was
> > worse now.
>
>
> Hmm… I can’t speak to parallel port, but I can’t see that it would be much different that any other APIC based interrupt. I’ve experimented with several serial interface chips, Intel and AMD with power management disabled, and the 6-7us seems pretty consistent. I would love to lower this, and am really open to suggestion if you have ideas. Yes, I know that MSI should be lower, and while I do have serial cards that support MSI, none of the Linux drivers support it for the chips I have. I haven’t been motivated yet to rewrite the drivers for MSI. :)

Well, as I said I made measurements which showed that the parallel port was of
the order of 1us. I vaguely recall that I also looked at the serial port and
it was worse, but I cannot remember any figures. The problem is that the
serial chip needs to register the interrupt and deliver it to the system.
Since serial ports operate at absurdly low baud rates, it is not so important
that the interrupt operate quickly, so I suspect manufacturers do not bother.

> > > can get better than this using a gpio and spinning on it, but I haven’t seen anyone do this
> >
> > Well, that is unclear, and hugely expensive in terms of taking up the time of
> > the cpu.
>
> It’s not completely free running. You run a loop that includes a pause which allows you to trade off between the duty cycle of the CPU and resolution of the pulse.

But in order to get 1usec resolution you would have to be running that loop at
MHz which leaves not much time And finding something which will pause reliably
at the 1us time scale is also hard.


> Denny
>
>
> --
> To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
> with "unsubscribe" in the subject.
> For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
> with "help" in the subject.
> Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.