Re: Clarifications about PPS SHM content

[Martin Boissonneault]

Hi Gary,

On 2020-03-25 15:16, Gary E. Miller wrote:

> Yo Martin!
>
> On Wed, 25 Mar 2020 02:31:29 -0400
> Martin Boissonneault <address@hidden> wrote:
>     
> > Do you feed ADSBexchange <https://www.adsbexchange.com/> and OpenSky 
> > network <https://opensky-network.org/>?
> >       
> I feed FlightRadar24, in return for a free business account.  They
> have good coverage in my area.  The adsbx looks so-so, and the opensky
> not good at all.  Any way to see where their feeders are?
>

I don't think you can see their feeder sites, but https://tar1090.adsbexchange.com/ shows all the current traffic. Feeding ADSBx uses your existing setup, with some scripts branching the data to their site. Same with opensky. Both of them are Linux-friendly, but not very user-friendly for installation. Call them "for intermediate users" if you will.

In addition of both of them, I feed my own Virtual Radar Server and the online sites FlightRadar24, FlightAware, RadarBox and PlaneFinder. My online favourite is FR24, with FlightAware and ADSBx as a seconds, but at home I use my VRS. You get no MLAT backfeed from FR24, but you can with FlightAware (good!) and ADSBx (needs more feeders, but sometimes great).

> > 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).
> >       
> Too big.  A 1 GHz a ground plane begger than about 60cm is sub-optimal.
>
> u-blox has some good white papers on the subject.
>

Thanks for the info!

I'm thinking of building cantennas to improve my ADS-B/UAT coverage quality and GNSS skyview, but I have to figure how to get the cables out first. At the moment, the washing machine cover (less than 50cm on the wide side) is little more than a metal shelf on the window sill. It's laughable by hamradio standards :-/

> > > I'd like to see real data to prove that.  
> > >         
> > See /initial_turbo/ there: Overclocking options in config.txt 
> > <https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md> 
> > and the thread 
> > <https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=6201&start=425#p180099> 
> > linked.
> >       
> I asked for data, not guesses.
>
> > 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?).
> >       
> Don't ask me, look at what your system tells you.  Data, not anecdotes.
>     
    On my dedicated time server RasPi, one day, then!
    
> > 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.
> >       
> ALL governors change the CPU speeds.  Only how much and when is different.
>     
    I'll try to read more about this, and the overall impact.
    
> > > The RasPi overheats at the drop of a hat.  Very rare to keep one
> > > running at full speed.  
> > >         
> > I put small heatsinks 
> > <https://www.buyapi.ca/product/aluminum-heatsink-for-raspberry-pi-b2-2-pack/> 
> > on and it doesn't usually overheat. My recorded stats show a handful
> > of potential overheats, which where probably when I recompiled the
> > kernel.
> >       
> "usually"?  I feel so much better now.  :-)
>     
    I never had to do anything about it, and I haven't seen any warning
    (not logged in to the Desktop, maybe there was some warning there,
    who knows!). My NTP stats are crap when it happens, but whatever
    temperature event it encountered was auto-managed. 
    
> > 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???
> >       
> Not much is you are using KPPS.
>

Good then! I care about precision, not the rest.

> > 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.
> >       
> And you confirmed that how?  Or you believed the amrketing?
>

I don't have the equipment to test. I must rely on the datasheet. So, I must rely on others who have the tools and skills to the fact checking, but I have no reason to doubt what's written in it so far. Many RTCs have a few external components like the crystal and capacitors, and those are as precise as your engineering made them, but the DS3231 is self-contained. As long as it's not counterfeit, it should meet the datasheet specs.

The major difference between this one and most others is that the entire clock system is built-in. No third-party parts with variable quality in the loop. No stray capacitance. No uncontrolled temperature changes. You can enable the 32.768KHz frequency output pin and measure frequency on it for test, calibration or other purposes. There is also another pin that can output 1Hz, 1.024KHz, 4.096KHz or 8.192KHz. I don't have the appropriate equipment, but if I had, I'd test it and get real-life data.

But does it matter? RTCs are never going to be close to GNSS PPS+NTPd anyway. As long as they provide a startup time, they have done their job. The rest is the burden of ntpdate or NTPd.

And when you think of time as electricity that travels in a wire (at ~66%  of the speed of light in a vacuum), a nanosecond is ~0.2m or ~8in. My RasPi has the "precision" (~300ns jitter) of within ~60m or ~195ft of cable, or within ~90m/~300ft of light travelling in vacuum!  Maybe I should try to reason myself that increasing the accuracy of my time server is an obsession with no tangible benefits except "bragging rights", but I will probably fail and do it anyway ;-)

> > > > /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.
> >       
> You should see less frequency jitter.  Not much, but noticeable.
>

I saw a few ns less jitter, but I'll wait a week, there is too much jitter due to my other testing to get a good data point. Unfortunately, something happened last night and my CPU temps jumped to a fairly precise 60°C

> > > 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.
> >       
> Then set your temp at 70C and leave it there all year.
>

I've set ntpheat -c 3 -t 68 for testing. Does it need to be niced? I have stats running at nice 19, will they still run if I don't renice?

For now, ntpheat won't survive a reboot, but I'll deal with that a bit later if the results warrant it.

> 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
>     
    Good evening!

Martin