If you’re close to 100% CPU then the Pi has a tendency to silently drop USB traffic, which means a) you might miss some messages and b) mlat synchronization is compromised.
My system load is well above 1 during the days - even when it’s overclocked.
An RPi2 is definitely what I’ll be buying next. Another one to add to the collection. Currently got 5 RPis and 2 RPi2s in active use for various things. A couple of spares waiting for other projects.
Top from my “stock clocked” B+ Getting tighter on memory as well as CPU… However, I was running a Pi2 in parallel and getting identical results with this current load.
If I do an in-place swap from PiB+ to a Pi2, will it have to be re-registered or will FA pick up a new MAC address associated with the same sending IP address? Joe K4AA
The problem with spoofing the MAC is, you might want to reuse the Rpi for another project. If you do that, you will now need to also spoof it’s address with another (if on the same local network). It would be great if FA would not use MAC addresses as reference with no way to change the MAC=site# association.
My stats are presently shot anyway - since I’ve had three long periods down time due to overheated dongles.
I do have a Pi2 that I’d need to build up for the job … I’d probably not spoof the old MAC address since I may want to use that old Pi for feeding elsewhere … but then again, it would save reconfiguring the router DHCP reservations, and port mappings.
I think the MLAT client is the straw that’s broken the camels back, it seems to have a lot of work to do.
Presently I’m reporting about 400,000 ADSB positions a day. For every two planes with full ADSB there is one with a simple responder 80% of which get located by MLAT.
(I’d like to get the counts up a little - but geography (= a rise in the land east to south east) gets in the way.
I quick fix now would be the medium overclock (since that wasn’t causing the crashes).
It’s not so bad if you think of it as a site identifier that defaults to being the MAC address.
(It could generate a UUID to serve the same purpose, but many of the common UUID generation mechanisms start from a MAC address anyway…)
What is really needed is a way to specify that site identifier / UUID manually.
I’m starting to associating an address (a bogus MAC address) with the boot image, rather than the hardware. this gives me an easy way to test different configurations.
That lets me move between a Pi B and a Pi 2 with a minimum of trouble. The new images also incorporate avahi-daemon, which supports easier addressing on a LAN, being able to SSH to oldcrow.local rather than having to remember or figure out where that particular little box is numerically on the network.
And yes, I’d like a sanctioned way to move my Flight-Aware stats to a new box/processor. The box I’ve been using as my main Flight-Aware feed is a 256mb Pi – replacing it with a Pi 2 and spoofing the old MAC address won’t be an issue, as I’m not going to reuse that 256mb machine!
How much of that load is collectd and related parts, because I only hit 0.30 load feeding the three sites. Granted I probably have less planes, but stats collection can be CPU hungry.