[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] NO_HZ Avoidance
From: |
Gary E. Miller |
Subject: |
Re: [gpsd-dev] NO_HZ Avoidance |
Date: |
Thu, 30 Jun 2016 18:48:31 -0700 |
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