Re: [gpsd-dev] NO_HZ Avoidance

[Gary E. Miller]

Yo Fred!

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.

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.

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

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

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

pgpAzeLIblqvu.pgp
Description: OpenPGP digital signature