Kernel PPS processing

[Achim Gratz]

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

> My Gentoo RasPi is at 4.4.14-v7,
> but wheezy is at 4.1.19-v7.

I've switched both RasPi to Jessie, which is at 4.4.13 at the moment.

> Worse my Odroid is at 3.10!

Leave those out of the discussion, they aren't RasPi.

> 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).  I don't think there are any other powersave features on the
RasPi.

> 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.  But keep in mind that the LF receiver with AM
demodulation I'm using at the moment isn't anywhere near as precise as
GPS and I'm far enough from the transmitter so that the propagation
delay has day/night variations (those are mostly swamped in jitter, but
you can just see them when looking at four hour averages).  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.  The residual over a full day is around 5µs and 20µs
respectively.  I'm trying to get the second one down, but it has a
slightly worse reception, so I'm expecting to hit bottom at around 10µs
without changing to a different antenna for instance.

I'm planning to clean up the received signal with a microcontroller and
maybe I can even decode the PM signal (but I also need a better antenna
for that) on that same board, which would get me down to some µs
accuracy after path delay compensation.  I've also ordered two GPS units
(USB with uBlox 6 and 8) which I think I can hack into to get the PPS
signal out they don't officially provide.  I may get a NavSpark mini
just for fun as well.

> Seemed to help about 5% for me.  I need a few hours of data to see the
> difference.  A good test takes days, but eventually I'll loop back and
> retest things.

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, but it seems that this an
interaction of the demodulation and AGC in the receiver, since it
normally only happens on the unit with the worse reception (plus 100ms
and 200ms is the tail end of the AM modulation pulse, so it also makes
sense that I would never see spikes in the other direction).  In any
case, the weekend was having rather uniform reception conditions and I'm
not seeing that tail of the distribution change significantly after
moving to nohz=off.  The main distribution width got a bit smaller since
I've added E-field shielding to the antenna.

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


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables