Kernel PPS processing

Gary E. Miller gem at rellim.com
Sun Jul 3 21:37:43 UTC 2016


Yo Achim!

On Sun, 03 Jul 2016 23:20:10 +0200
Achim Gratz <Stromeko at nexgo.de> wrote:

> Gary E. Miller writes:
> >> No.  That used to be "force_turbo=1", but is not needed anymore.  
> >
> > As of what kernel?  I notice RasPi's have all sorts of weird kernel
> > versions and patchsets.  
> 
> I've not kept notes, but the first Raspbian installation from about
> two years ago already didn't need it (until you wanted to void the
> warranty by overvolting also).

Thanks.

> > Worse my Odroid is at 3.10!  
> 
> Leave those out of the discussion, they aren't RasPi.

They run the same Gentoo as RasPi, just an older kernel.  Not sure why.

> > Do I need to do this, or is 'performance' enough?  What would you
> > put in config.txt to set the performance governor?  
> 
> If you haven't done any setup for lower and higher frequencies, the
> governor will never change frequencies (since there is only one to
> chose from). 

When I had 'ondemand' set (the default), and nothing else set, my RasPi it would toggle between a high and a low frequency.  And that took some time to settle.

> > How are you measuring?  Eyeballing 'ntpq -p' or running a week of
> > gnuplots?  
> 
> Looking at the distribution of PPS arrival times and the resulting
> time offset in the loopstats.

You'll need some automated tools to see 5% changes.

> As long as there's no thunderstorm around it'll keep time
> within +-3ms range for the raw offsets taken every 16 seconds and
> +-300µs averaged over 3.5 minutes.

A GPS HAT will beat that by over 100x.  If that matters to you.
Plug and play.


> Based on your time plots I'm probably not able to see that small an
> improvement.  I was trying out the nohz=off in hope to get rid of PPS
> spikes that are alway 100ms or 200ms late,

I see something like that, just not as big a spike.  Turned out to be
cron jobs.  I'm now nice-ing my cron jobs.

> >> Keep in mind that the PPS
> >> timestamping is actually done by the VC4 and not the ARM in the BCM
> >> SoC.  
> >
> > Very interesting.  That is a new twist.  Got a citation for that?  
> 
> The BCM SoC actually is a media processor with an ARM subsystem and
> not the other way around as typically found elsewhere.  The timestamp
> counter and all I/O is provided by the VC4.

Got a citation for that?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160703/71208600/attachment.bin>


More information about the devel mailing list