Re: [gpsd-dev] NO_HZ Avoidance

[Fred Wright]

On Thu, 30 Jun 2016, Gary E. Miller wrote:
> On Thu, 30 Jun 2016 18:25:10 -0700 (PDT)
> Fred Wright <address@hidden> wrote:
>
> > I see the recently added recommendation to disable NO_HZ on ARM.  This
> > doesn't make sense when using the KPPS driver to capture the PPS
> > timing with interrupts, since I really don't see how adding more
> > clock interrupts is going to improve the accuracy of servicing the
> > PPS interrupts.
>
> I'm still learning about the ARM power savings.  As a general rule
> tickless operation lets tha CPU go into deeper power saving states, which
> is not what we want.

Even if that's true (which isn't entirely clear), it may be negligible
depending on which level of power state it actually goes into.

It's not clear that that mechanism is even active on the BBB (at least in
the relevant Debian setup), given the absence of the
/sys/devices/system/cpu/cpu0/cpuidle/ directory.

> I've got  week of stats here:
>       https://pi3.rellim.com/
>
> You'll notice a gap in the data late June 29 (UTC).  That is when
> I rebooted a new kernel with tickless off.  You gota squint at it, but
> it does seem to be that the 'Local Time Clock Offset' is better.
>
> The 7 day offset (90%) is 23 microSec.  The 1 day offset is 22 microSec.
>
> Not big, but obvious to my eye, and measureable in the 90% bounds..
> I'll take anything I can get.

Well a one-microsecond difference is pretty small compared to the actual
interrupt latency, which is probably at least an order of magnitude
larger.  And you'd need a *much* longer measurement to prove a consistent
correlation.

I see a diurnal variation in your frequency data, which is most likely
thermal.

> > My BBB time server is running with NO_HZ enabled, and it doesn't seem
> > to adversely affect the PPS timing:
>
> We are playing with variables that can take days to make a difference.
> ntpq will not show you data to better than 1 microSec.  The ntpd logs
> do.  You need to find a way to do a 1 day or 7 day log analysis.

It's also worth noting that, without PTP or similarly enhanced NTP,
there's no way to transfer that degree of accuracy to another machine,
anyway, even on a LAN.

> > I wouldn't expect to do better than that with anything that's at the
> > mercy of interrupt latency.
>
> Yeah, the consensus seems to be that the interrupt latency of a RasPi can
> be 20 to 70 microSec, or more.  My data supports that.

On the BBB I've meaured it (admittedly via a somewhat "heavyweight"
method) as typically about 14us (occasionally much longer, as one would
expect).  This is of course completely invisible to NTPd, which can only
go by what the PPS driver reports.

To measure it less invasively, I'd want to patch the KPPS driver to
*output* a PPS signal right at the time that it timestamps the incoming
PPS event, so that one could observe the latency on a 'scope.


The AM3358 used in the BBB has hardware features that could improve this
dramatically, but software work is needed to exploit them (and a jumper
wire, since the GPIO that Yantrr picked for the PPS signal isn't
ECAP-capable).  In principle, one could get both hardware-captured timing
of the PPS signal and hardware timestamping of the network packets.
AFAICT, none of the other low-cost SBCs has this property.

Fred Wright