|
| From: | Martin Boissonneault |
| Subject: | Re: Clarifications about PPS SHM content |
| Date: | Wed, 25 Mar 2020 02:31:29 -0400 |
| User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 |
Hi Gary,
Yo Martin! On Tue, 24 Mar 2020 02:14:03 -0400 Martin Boissonneault <address@hidden> wrote:I don't have much experience with Debian/Raspbian/Linux optimization and process tracking. I struggled to find the cause of the time error spike that was caused by systemd's timesyncd service.Well, systemd(umb) says it all. "Just Say No" (tm)Well, to the defence of whoever put timesyncd there, the logic is sound: Get the time right before the system starts too much to prevent the time from jumping backwards because of no RTC or one that's too far off.Fine for coarse adjustment on eyond that, the systemd(ibble) people are not time-nuts.But otherwise, it's in direct conflict with any other type of time synchronization. So, m'kay...One could say that os all of systemd(umber).I have a Nooelec NESDR SMArtee for comparison, and the LNA does help me pull in more planes.I see 300 miles do I really better?
I envy your reception! I currently cannot do better as I have no
way to cable the antennas to the outside. Remember that the
FlightSticks are meant to benefit most users, especially the mass
who won't have a great setup, probably in urban centers. The
inboard LNA benefits the common indoors mini-antenna hooked by a
few feets of thin cable. Unfortunately, I'm one of them :-(
Do you feed ADSBexchange and OpenSky
network? The first shares everything, including MLAT and
blocks no planes. and tar1090.adsbexchange.com is very nice with
persistance! The second is used for research. I wonder if you feed
UAT 978MHz?
Both are fed by small antennas with a good ground-plane a few feet away.At a GHz you want the ground plane directly the antenna.
ROTFL!!! No, my ground is not a small bag of dirt attached to the grounding wire ;-) The antennas are a few feet from the receivers, with a ground plane (cover from my old washing machine).
The receiver has been working well for over a year now! Rock-solid, not a single disconnection.Yup, the RasPi's are rock-solid.
Agreed! The RasPis have opened a whole world of computing, that of cheap everything computing. I want more, for sure!
I tested that about a year ago, so I don't have the numbers. But I ran /CONFIG_NO_HZ_COMMON=y/ (stock), then CONFIG_HZ_PERIODIC=y with 100Hz, 250Hz and 500Hz and 250Hz had the less jitter of the four configurations.Good to know. I have not tested. Some people recomment the NO_HZ, without the data to prove it.Considering the compile time on my Pi,Who cares how long it takes. As long as it is less than my nightly eight hours. My problem is so many things to test...
Well, I put this on my TODO list. Don't hold your breath though!
I think the reason to set it in the kernel .config has to do with the timing calibration of the kernel, as the governor that is active on boot uses a different frequency before the OS configuration changes it (600MHz vs 1400MHz).I'd like to see real data to prove that.
See initial_turbo there: Overclocking
options in config.txt and the thread
linked.
I do use initial_turbo=60, so the maximum speed is used until 60 seconds or until cpufreq sets a frequency, which will be done by the performance governor in my configuration (Right?).
There where a few cases where if the frequency drops before the kernel bootup is complete, a mis-calibration of the BOGOmips could occur and affect all timing loops. SD corruption occurred. I'm somewhat sure the corruption issue has been fixed since, but it makes sense to have the CPU use the same governor all the time instead of possibly hopping from one speed to another on time servers.
I think there is a mechanism to fix this (a delay before lowering the frequency), but hard-setting it in the kernel ensures that the calibration will run with the frequency that will be used normally.The RasPi overheats at the drop of a hat. Very rare to keep one running at full speed.
I put small heatsinks
on and it doesn't usually overheat. My recorded stats show a
handful
of potential overheats, which where probably when I recompiled the
kernel.
I'm confused:
sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq 600000 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 1400000
So, the frequency is scaling from 600MHz to 1.4GHz? What does
that do to NTPd???
Something swung your frequency hard at 23 Mar 12:00ZHa! Yes, I tested an offline boot, only to find out my RTC was off half an hour for some reason. Being an DS3231 RTC with battery backup, it shouldn't be off more than a few minute a year.Just now on #ntpsec someone was proclaiming how good their RTC is. I never trust them.
Well, some like the DS3231 are pretty good as they use a TCXO,
they apply a capacitive correction factor to the oscillator
depending on the ambient temps. The frequency precision on that
one is from ±2.0ppm to ±3.5ppm without any calibration. It CAN be
calibrated by setting an aging offset. The accuracy of the
RTC is only useful over long periods when powered off, short term
any will do! Especially when running NTPd.
According to timedatectl, my system clock and RTC are in sync and kept in sync. That's all I care about, my RasPi is always on and the RTC is only needed for short periods of time. All I can think about the offset was that my previous RasPi config had something wrong, or something weird happened when my USB-connected SSD started to get corrupted.
Nice. Your disk I/O is a bit high for best timing. Maybe buffer that more?Good idea! How about I do it right now? I changed /vm.dirty_expire_centisecs/ to 2.5 minutes,/vm.dirty_ratio = 40/ and /vm.dirty_background_ratio = 30/. Do you think that's allright?You tell me. Did it help or hurt?
I/Os are down, but I don't see a significant impact on time.
Well, my u-Blox MAX-M8Q is configured for a static position (it is static). It's height is also configured from the 1-week long position averaging. * UBX-CFG-PRT set baudrate to 115200, [...] * and saved the config to bbRAM.And good to verify those setting occasionally.
Yes, for some reason I lost my settings in the past because of (shuffles excuses card pack and picks one) Cosmic rays ;-)
Should I turn the Fix mode to 3D and leave TMODE2 Time mode to 2-Fixed?Time mode is suposed to be best for timing. Something else to test in your spare time. :-)
Just quickly tested it, and toggling 2D/3D in UBX-CFG-NAV5->Fix mode changed the TDOP by about 0.2. Lower (better) in 2D mode. The altitude, being known, removes one uncertainty from the equations I guess. More testing in summer with the antenna outside will be a better data point.
It seems that UBX-CFG-TMODE2 does not work on the MAX-M8Q, the message returns a NAK. So, 2D/3D might have some real impact.
Your temp change is so small that cpuheat may be enough to get it solid. No cost to that.On my TODO list, there's cpuheat. My problem is summer with the big south-facing window during heat waves. In winter, there is no problem, it can generate it own heat, but in the summer with high ambient temps, it becomes HOT. I've put the plastic cover on the case for the winter (room temperature set to 18__C, door kept almost closed) but in the summer I only leave a piece of paper in place of the cover.Optimal OXCO temp is pretty high, I seem to remember near 55C? If your house gets that hot in the summer you have other problems.
Of course it doesn't, but it reached and held near 40°C for days. Consequently, the RasPi cooling was less efficient, and it's temps shot up above 65°C, with only a piece of paper as a cover. It's visible in my graphs between June and October 2019.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
address@hidden Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
| [Prev in Thread] | Current Thread | [Next in Thread] |