modesmixer2 and MLAT data on port30004

[obj]

@N456TS

Please give your argument for this. Free CPU just misleads people thinking that everything is a-ok, as their system is running bogged down. Free CPU is the bad metric, not load average.

last pid:  7790;  load averages: 30.10, 29.31, 27.02   up 12+09:47:23  02:26:31
2448 processes:3 running, 2442 sleeping, 3 zombie
CPU: 37.3% user,  0.0% nice, 30.8% system,  4.0% interrupt, 28.0% idle

(10 CPU system, running healthily)

[obj]

@N456TS

Yes. A load average of 4.0 on any system regardless of the number of CPUs would indicate the CPUs are 300% overloaded.
A 1.0 means they are fully loaded. A 0.50 means they are 50% loaded, etc.

This is not correct at all.

To avoid playing the game of Citation Needed…
See: https://en.wikipedia.org/wiki/Load_%28computing%29

This page disagrees with what you have said above.

@wikipedia

For systems with multiple CPUs, one must divide the number by the number of processors in order to get a comparable percentage.

You’re also missing that load average is a periodically sampled value, and deals particularly badly with measuring bursty loads or thundering-herd type situations.

[N456TS]

For systems with multiple CPUs, one must divide the number by the number of processors in order to get a comparable percentage.
You’re also missing that load average is a periodically sampled value, and deals particularly badly with measuring bursty loads or thundering-herd type situations.

You’re correct, I did miss that. Multiprocessors didn’t exist when I used to play with this. However, ignoring load average is like saying “I have the fastest processor in the world, but the bus is 50mhz, SCSI1 HD and 16MB of SIMM. My free CPU is high, but my load average is 10.00. I guess there is nothing wrong”.

I argue you need to monitor the whole system, not one part of the system. I don’t care “how free” the CPU is if other components are too slow to complete the task in a timely manner.
“Free CPU” only states:
A) You have less work to complete then you’re capable.
B) You have ample work, but the CPU is underutilized because it’s waiting.
You can’t tell if you fall into category A or B with only the free CPU %.

I believe some have been seeing scenario B in heavy MLAT locations. I did with a Rpi B+.

From the article linked to above:

The problem with a load of 1.00 is that you have no headroom. In practice, many sysadmins will draw a line at 0.70:

The "Need to Look into it" Rule of Thumb: 0.70 If your load average is staying above > 0.70, it's time to investigate before things get worse.

The "Fix this now" Rule of Thumb: 1.00. If your load average stays above 1.00, find the problem and fix it now. Otherwise, you're going to get woken up in the middle of the night, and it's not going to be fun.

The "Arrgh, it's 3AM WTF?" Rule of Thumb: 5.0. If your load average is above 5.00, you could be in serious trouble, your box is either hanging or slowing way down, and this will (inexplicably) happen in the worst possible time like in the middle of the night or when you're presenting at a conference. Don't let it get there.

The above quote is in reference to a single processor.

[donf99]

I am running a Pi, Version 2 with 4 cores.

The literature on load average is pretty definitive about a load average of 4 being the optimal maximum load for a quad-core system - 1 per core.

The cars/lanes analogy in one of the cited links supports this. 4 cores represents 4 “lanes” of capacity. A load average of 4 on a quad core system means that there are 4 waiting processes in the run queue, with 4 cores to (simultaneously) process them.

What I find puzzling is how the long list of processes and their individual CPU %s relates to the aggregate CPU utilization numbers. just below the load averages in “top”. If one sums the individual task percentages shown in the list, the total is usually around 100% (but not always) and does not match the 25% utilization in the upper part of the “top” screen. BTW, individual core CPU %s may be toggled by pressing the digit “1” on the keyboard while “top” is running.

CPU overload on my Pi B+ would be accompanied by the the blue FIFO overrun LED flashing on the Mode-S Beast, as the CPU was unable to service the virtual serial port over USB to accept all of the data before the FIFO overflowed. I NEVER see a blue LED flicker on the Beast with the Pi v2.

Best,

Don
WD9DMP

[obj]

@N456TS

I argue you need to monitor the whole system, not one part of the system. I don’t care “how free” the CPU is if other components are too slow to complete the task in a timely manner.

.
Ok. If you think that load average is a better measure than free CPU, I don’t feel the need to convince you otherwise.

I’ll still keep asking for CPU figures and not load average, though, because my experience is that - especially with piaware, which is a compute-bound load! - free CPU is exactly what you need to look at. (And then there’s the whole “USB subsystem drops data if there is not much CPU free” which is a very important consideration for mlat).

[obj]

@donf99

What I find puzzling is how the long list of processes and their individual CPU %s relates to the aggregate CPU utilization numbers. just below the load averages in “top”.

By default the individual process figures are expressed as “percentage of a single core”. If you’ve got a heavily loaded multithreaded process you can see percentages above 100% here. This is “Irix mode”; you can switch to “Solaris mode” which expresses them as “percentages of the whole system” by hitting capital I.

The aggregate CPU numbers are expressed as “percentage of the whole system”.

[Kabuse]

@obj

@N456TS

I argue you need to monitor the whole system, not one part of the system. I don’t care “how free” the CPU is if other components are too slow to complete the task in a timely manner.

.
Ok. If you think that load average is a better measure than free CPU, I don’t feel the need to convince you otherwise.

I’ll still keep asking for CPU figures and not load average, though, because my experience is that - especially with piaware, which is a compute-bound load! - free CPU is exactly what you need to look at. (And then there’s the whole “USB subsystem drops data if there is not much CPU free” which is a very important consideration for mlat).

Recently, I did a bit of research about comparing the both of them and came around this:

http://www.teamquest.com/import/pdfs/whitepaper/ldavg1.pdf

http://www.teamquest.com/import/pdfs/whitepaper/ldavg2.pdf

I also think CPU consumption is right, since load average smoothes the peaks out.

Kabuse

[donf99]

@obj

@donf99

What I find puzzling is how the long list of processes and their individual CPU %s relates to the aggregate CPU utilization numbers. just below the load averages in “top”.

By default the individual process figures are expressed as “percentage of a single core”. If you’ve got a heavily loaded multithreaded process you can see percentages above 100% here. This is “Irix mode”; you can switch to “Solaris mode” which expresses them as “percentages of the whole system” by hitting capital I.

The aggregate CPU numbers are expressed as “percentage of the whole system”.

Thanks for explaining this. It all makes sense now.

Bottom line - my RPi 2 seems to be using about 25% of its CPU resources, measured by load average or CPU util. It appears I have sufficient capacity to run the two instances of modesmixer2, PlanePlotter ppup1090, Piaware with MLAT, and the modesmixer2 web server with no issues.

Don
WD9DMP

[sjacket99]

I setup ModeSmixer2 on a spare Netbook computer just for something to do and new. I never use ModeSmixer2 before. I have 2 Raspberry Pi sites feeding FA and I have setup ModeSmixer with the following command to get it working.

./modesmixer2 --inConnect 192.168.0.114:30005 --inConnect 192.168.0.102:30005 --web 8088 --location xx.xxxxxx:-xx.xxxxxx

I can see the stats and the planes on the map and all. Im sure I can do more with this, but I am just learning this. The question is can I feed MLAT into this?

Also anyway setting up to save a database using this? I know you can create a database and save it to the computer using VRS.

Any help would be great. Thanks again for the help.

[idh]

From my own notes to do this:

Output from “sudo piaware-config -show” was:

mlatResultsFormat {beast,connect,localhost:30104 ext_basestation,listen,30106

To avoid upsetting the working Piaware setup, I tried adding a new listen port with Beast format and restarting:

sudo piaware-config -mlatResultsFormat "beast,connect,localhost:30104 ext_basestation,listen,30106 beast,listen,31003"
sudo service piaware restart

Now there should be MLAT data in Beast format on port 31003. Combining the ADSB traffic on port 30005 gives all the data from Piaware:

modesmixer2 --inConnect <Pi IP>:31003 --inConnect <Pi IP>:30005 --web <port>

Adding a BaseStation.sqb and silhouettes gives me want I wanted: a radar screen with each aircraft labelled with registration, call sign and altitude.

[sjacket99]

Thanks for the information.

[sjacket99]

I have a off the wall question. I am new to the modeSmixer thing. The question is if I had 2 Pi’s hooked up to it’s own antenna. Could I feed the data from both into a third Pi to feed data to FlightAware using modeSmixer?

I guess I would only install Piaware on the third Pi? Would I only install Dump1090-Mutability on the other 2 Pi’s?

Any help would be great. I’m not saying I plan on doing this, I just had a thought.

Thanks.

[N456TS]

@sjacket99

I have a off the wall question. I am new to the modeSmixer thing. The question is if I had 2 Pi’s hooked up to it’s own antenna. Could I feed the data from both into a third Pi to feed data to FlightAware using modeSmixer?

No. That would break MLAT. Prior to MLAT, that could be done.

[sjacket99]

@N456TS

@sjacket99

I have a off the wall question. I am new to the modeSmixer thing. The question is if I had 2 Pi’s hooked up to it’s own antenna. Could I feed the data from both into a third Pi to feed data to FlightAware using modeSmixer?

No. That would break MLAT. Prior to MLAT, that could be done.

Thanks for the reply…

[caius]

@N456TS

@sjacket99

I have a off the wall question. I am new to the modeSmixer thing. The question is if I had 2 Pi’s hooked up to it’s own antenna. Could I feed the data from both into a third Pi to feed data to FlightAware using modeSmixer?

No. That would break MLAT. Prior to MLAT, that could be done.

Not necessarily, it depends on how you do it. If the two existing pis are both running a receiver each with its own instance of piaware, then that will work OK since each can talk to the mlat server independently. You can then run a third pi running another instance of dump1090 in network only mode, or modesmixer which connects to the other two.

What won’t work is connecting both receiver pis to a third, and then running piaware on the third one.

[N456TS]

@caius

What won’t work is connecting both receiver pis to a third, and then running piaware on the third one.

That’s the specific scenario he proposed.

[sjacket99]

Thanks for the replies. Might have to think this out.

[obj]

The underlying problem here is that there is no way in the protocols used to exchange Mode S messages to identify the receiver that originally received the message. The mlat server needs to track each receiver’s clock separately. Without a way to identify separate receivers in a single feed, it has to assume that all data from one feed is from a single receiver.

[sergsero]

Hello,

Now there is a beta test version of modesmixer2 (v.20151226), in which can to mark a particular port in mode:

--inServerId <Port:Label>

The input data format will be determined automatically.

It will be made finalized for release to solve some issues, however I would be grateful to know, could there be demand for such a mode to display the MLAT aircraft.

For test only: modesmixer2 (v.20151226) http://radarspotting.com/forum/index.php/topic,2978.msg27353.html#msg27353

A description of the available program options can be found here: http://xdeco.org/?page_id=48

Regards,
sergsero

[sjacket99]

Thanks for the help.