Re: [gpsd-dev] NO_HZ Avoidance

[Gary E. Miller]

Yo Fred!

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.

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


> > 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'll take 5% any place I can get it.  5% here, 5% there, and all of a
eventually you have real change.  And yes, it will be a week before I
have really solid numbers.

And when I have NO_HZ=off, then the people telling me I need it can
see exatly how much it helps.


> 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
house is un-airconditioned and its temp takes many days to change.  I also
see that effect when I compare to my thermometer.

I'll prolly need to add a thermometer to my setup as yours is a frequent
mistake.

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

Practical?  No one ever mentioned practical.  :-)

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.

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.

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

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

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

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

pgpbElBnF6KaK.pgp
Description: OpenPGP digital signature