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 _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
