Re: [gpsd-dev] NO_HZ Avoidance

[Gary E. Miller]

Yo Fred!

On Fri, 1 Jul 2016 20:33:38 -0700 (PDT)
Fred Wright <address@hidden> wrote:

> > > > 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 5%.  S owe disagree on how many % nagligible is.

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

I'm not gonna worry about it.  I was asked to try it, it works for
me.  YMMV.

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

no_hz=off turns off tickless.

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

Clearly we don't agree on the words, so I'll just respond: 5%.

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

The GPS sats return to the exact same positions, as a group, every
sideral day.

This has been discused on time-nuts.  They consider it settled fact.

If you want clarification, I suggest you go over there.


> One would expect DGPS to help with that,

I have a WAAS signal.  That provides the same corrections as DGPS.


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

I stand by my data.  I encourage you to replicate the experiment.

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

Check out PWM mode:

https://www.npmjs.com/package/raspi-llio
https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

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

Then you lost me.  I thought the whole point was to measure reported PPS
time?  We are talking NTP here, right??

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

I never claimed it was.  I only claimed that ntpd reports down to
nanoseconds.  I never claimed that as accuracy, only as resolution.

And I mentioned it because you claimed to be limited to microSeconds,
where it is clearly deomonstrated that ntpd can do better, even on
the Pi.  Play with your logstats, you'll see, real data in there.

My results speak for themselves, show us yours.

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

That was also my understanding.

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

I'll take ugly if it buys me accuracy.

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

When I grow up I wanna be a hacker!

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

pgpOVNaMhkdeA.pgp
Description: OpenPGP digital signature