Re: [gpsd-dev] NO_HZ Avoidance

[Fred Wright]

On Thu, 30 Jun 2016, Gary E. Miller wrote:
> On Thu, 30 Jun 2016 20:04:04 -0700 (PDT)
> Fred Wright <address@hidden> wrote:
>
> > 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.
>
> Maybe, but not negligible in my case.  With NO_HZ off I'm running a
> whopping 5v and 0.400 amps.  Since I am on the AC mains the power
> savings is too small to worry about.

I meant negligible in terms of the timing effect.

> > It's not clear that that mechanism is even active on the BBB
>
> well then, you have some kernel compiling and long term testing to do!
>
> > given the absence of the
> > /sys/devices/system/cpu/cpu0/cpuidle/ directory.
>
> I'm not sure how that is relevant.  I do not have that either, yet
> NO_HZ=off clearly helps my RasPi.

The processor doesn't magically use deeper C states on its own - a kernel
driver is required to do that.  From what I can tell from documentation on
that, this is normally handled by the "cpuidle" driver, which exports the
aforementioned variables (including reporting what the latencies are for
exiting from the supported C states).  The absence of the variables
indicates that the driver isn't active.

It does appear that default state of the *frequency* governor is
influenced by whether it's running "tickless", but that's an overridable
default.

In any case, "clearly helps" seems like a bit of a stretch. :-)

> > I see a diurnal variation in your frequency data, which is most likely
> > thermal.
>
> Nope.  That is due to the sidereal day effects of the sat orbits.  My

That seems unlikely.  Each satellite has a different path through the sky
during its period of visibility, and of course satellites come and go over
periods of around six hours.  The probability that thwt complicated mess
could just happen to turn into something looking very much like a daily
sinusoid seems *very* unlikely.

If it's a GPS-side issue, it's more likely due to uncompensated
ionospheric variations.  Those would follow *solar* days, not sidereal
days.  The difference is too small to see in a week, but comparing
correlations with time of day at different times of year would show it.

One would expect DGPS to help with that, since one of its main effects is
to provide better ionospheric compensation (as well as for satellite clock
and orbit errors).  But I note that the U-Blox documentation recommends
*disabling* DGPS for timekeeping purposes.  Perhaps they're applying
corrections in an overly rude fashion.

> Actually, if you look further down my URL, you'll see that a 20 microSec
> offset between my local RasPi's is normal.  Or, you would se it, except
> for a reboot swamping the graph there.  Another generation or two of
> RasPi and it might be that it will get PTP.

Highly unlikely unless they switch to a better processor.  I'm pretty sure
the NIC in the Pi has no hardware timestamping capability, and of course
it's a totally lame crock that's connected via USB.  An undocumented USB
controller with a binary blob for a driver, no less.

> The RasPi also has some counter timers in it and some people have been
> connecting those to the CPU clock.  Way down on my todo list, but
> making the RasPi a cheap GPSDO , with variable frequency output, is a
> possibility.

I'm pretty sure the Pi has no ability to time a GPIO signal with hardware.
If you know otherwise, feel free to post the section of the documentation.

> > 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.
>
> Look in the ntpd stats files.  ntpd logs things to the nanoSecond.

It could log things to the attosecond and that wouldn't change the fact
that it only sees the *reported* PPS time, not the actual PPS time, which
was my point.

Also, the GPS PPS isn't really good down to single nanoseconds, anyway,
for a number of reasons.

> > 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.
>
> I believe that kernel driver exists.  I'd love to hear your results.

It would have to be part of the KPPS driver itself to be useful.

> > 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.
>
> I have heard of some kernel hacks for the RasPi to get the internal DMA
> to hardware timestamp the PPS.  I look forward to seeing more work on
> that.

Doing it via DMA is a rather ugly approach, and still requires that the
GPIO can be routed to something the DMA controller can see.

The AM3358 has a couple of copressors that can be used to offload
time-critical tasks, but there isn't really a need to use them for this
when the event capture facility does exactly what one wants.

Remember the Pi was designed for schoolkids, not hackers. :-)

Fred Wright