Board index FlightGear Support Tools FGCom

FGCom 3.5 & Openradar

FGCom is a realtime voice communication system specially designed for FlightGear.

FGCom 3.5 & Openradar

Postby daweed » Mon Jun 22, 2015 10:54 am

Hello evryone,

Well, i am actually using mumble for vocal communication due to, in my mind, a bad working of FGCom.
But, maybe i need to check parameters or something else.

Well, i am using 3.5 Git version of FG and when i start OpenRadar, i start with external FGCom to use FG3.5 FGCom binary and not he one include in the OR install.
But i have discovered that the 2 processes launched for FGCom take each 100% Core cpu, so 2 cores of the cpu are only use for FGCom.

I don't think that it's a good way that a process should work, that's why i am currently using Mumble. But it's too bad to have a comunication tool that have been made to use frequencies can't work properly.

So if anyone can tell me where i can have a look ... that would be cool

Best regards

Daweed
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGCom 3.5 & Openradar

Postby vector » Tue Jun 23, 2015 9:02 am

I ran a test with Daweed last evening, and confirm that the fgcom process (in my case a single one, started from ATC-pie) eats a whole CPU core. Doing a tcpdump shows a very high traffic with fgcom.flightgear.com server as soon as the process is started as if the comm was permanently sending audio, not just when pushed to talk (~ 3k packets per second in reception). Only when dialing the echo freq (910) is the tcpdump showing a normal traffic e.g. only sending packets when one speaks (from 0 to 3k packets both in emission and reception). Same behaviour occurs with fgcom 3.4 and 3.5. If I run the test from the command line, starting fgcom directly and not through OpenRadar or ATC-pie, the fgcom process only shows a 5 to 6% max of CPU load, not the 100% load I get when started from OR or AP. Similar high network traffic occurs with fgcom active in fgfs, e.g. there is a constant reception traffic of ~ 3k packets/second even when no audio is exchanged on the audio channel. In the case of fgfs, the load doesn't climb abnormaly.

So for me there are two distinct questions:

- is fgcom supposed to burst continuously packets (received) when there is no audio sent/received on a channel?
- why is fgcom standalone eating a whole CPU/core when started from OpenRadar or ATC-pie? (thread issue?)
vector
 
Posts: 24
Joined: Wed Apr 17, 2013 8:40 am
Location: FR
Version: git
OS: Archlinux

Re: FGCom 3.5 & Openradar

Postby mickybadia » Wed Jun 24, 2015 12:57 pm

Hello,

[Note for those worried about this as other worries were expressed in other threads: this is not a feature problem but a network/CPU load optimisation issue. As far as I am concerned, the radio feature works fine as things are, though the concern will be more serious with old machines as more load will mean slow-down.]

After a few tests and a version history search, I suspect the problem is neither ATC-pie nor OpenRadar, nor the FGCom server alone, and rather involves new FGCom 3.4 client released in January before which the problem does not occur.

Taking ATC-pie commits for the sake of argument, here is the relevant part of the project chronology:
(a) commit e51c0 (Jan. 25)
Uses older FGCom 3.0 client and older FGCom server at the time, maintained by Clément
(b) commit 85325 (later same day)
FGCom client version change to just released stable version 3.4
(c) reported problem (Feb. 18)
CaptB and henrikp report that FGCom is not working on Windows while all Linux users have it working fine
(d) commit 6235d (Feb. 19)
Thanks to Clément who found what the problem was, Wolfram and I could solve the problem: the new FGCom server was expecting a new SILENCE_THD value in every packet which was not documented and for some reason defaulting to 0 on Windows only
(e) server change (April)
A new FGCom server takes over, maintained by Kévin Seroux.

Running ATC-pie on the listed commits with current FGCom server clearly shows:
(a) less than 1% of CPU load for either echo test or regular frequency
(b) less than 1% of CPU load for echo test and a 1-core 100% load for regular frequency (like what vector here is saying)
(d) same as (b)

So one question is: was the problem ever noticed between late Feb. and late March, i.e. when the new client and old server combination would be in place? If not, the current server might be part of the problem, but in any case the 3.4 client is.

To be honest I do not know what exactly could be happening technically as my job is pretty much limited to encapsulating a client instance under ATC-pie, and Wolfram would probably say the same for O-R. At (d), Clément explained to me that the 0 value for SILENCE_THD was in fact muting the microphone, which is why others could not hear when ATC used Windows. I have tried placing the 0 value back with latest config to see if it inflicted on the packet load, but it did not.

Funny the problem does not happen with echo test. For comparison, here are the differences in the command line options:
- for echo test: --server --port --callsign --frequency
- for regular freq: --server --port --callsign --airport
mickybadia
 
Posts: 475
Joined: Tue Sep 24, 2013 10:12 am

Re: FGCom 3.5 & Openradar

Postby KL-666 » Thu Jun 25, 2015 11:26 pm

What is exactly the deal with fgcom? If i look at fgcom.flightgear.org i see 3 lonely die hard atc's persisting in using it by themselves. If i look at Mumble, i see dozens of active users and atc's. Why not become part of the community?

Kind regards, Vincent
KL-666
 
Posts: 781
Joined: Sat Jan 19, 2013 2:32 pm

Re: FGCom 3.5 & Openradar

Postby wkitty42 » Fri Jun 26, 2015 2:34 am

seems to me that some are willing to try to get FGCOM fixed instead of using some 3rd party method... personally speaking, mumble will not pass by my firewall or security rules...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FGCom 3.5 & Openradar

Postby daweed » Fri Jun 26, 2015 5:41 am

What are u calling "3rd party method" ?
As i said if u know how to make that working , bring back the solution instead
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGCom 3.5 & Openradar

Postby jomo » Fri Jun 26, 2015 6:57 am

I would like to second the:
KL-666 wrote in Thu Jun 25, 2015 11:26 pm:What is exactly the deal with fgcom?

Is there still someone feeling some responsibility for it's functionality and support?

Some FGFS members may know me as major supporter for FGCOM over many years - but the last 2 years FGCOM just was not trustworthy any more - so I (and many others being interested in "Radio-usage") had to switch to mumble. Still I believe FGCOM would be great for those "Real-Life" enthusiasts for there special events - while "mumble" is much easier to use for FGFS-beginners (like e.g. at the EDDF-Triangle). But all that is not worth to discuss - as long as there is nobody feeling responsible for providing a trustworthy application! Just discussions about what could be the fault and "third party problems" etc. etc. pp. are senseless - they will just destroy the rest of trust-ability in that application!
jomo / ATCjomo + EDDFjo + EDDFjo1 + EDDFjo2
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 1000
Joined: Thu Feb 12, 2009 7:46 pm
Location: Mainz, Germany
Callsign: jomo EDDFjo1+2
OS: UBUNTU 18.4

Re: FGCom 3.5 & Openradar

Postby KL-666 » Fri Jun 26, 2015 12:15 pm

Hi Wkitty42,

Mumble needs only one rule, well pair of rules:
1) Allow new TCP and UDP connections to the Mumble server and port you use.
2) Allow TCP and UDP responses over established connections from that server and port.

Standard firewalls do not block such connections. They allow every new outgoing connection and responses from established connections. All they disallow are new incoming connections. So you probably locked down your firewall and block all outgoing connections. In that case you need the rule pair above.

Kind regards, Vincent
KL-666
 
Posts: 781
Joined: Sat Jan 19, 2013 2:32 pm

Re: FGCom 3.5 & Openradar

Postby daweed » Fri Jun 26, 2015 3:24 pm

KL-666 wrote in Fri Jun 26, 2015 12:15 pm:Hi Wkitty42,

Mumble needs only one rule, well pair of rules:
1) Allow new TCP and UDP connections to the Mumble server and port you use.
2) Allow TCP and UDP responses over established connections from that server and port.

Standard firewalls do not block such connections. They allow every new outgoing connection and responses from established connections. All they disallow are new incoming connections. So you probably locked down your firewall and block all outgoing connections. In that case you need the rule pair above.

Kind regards, Vincent


I do not think this is a technical problem for Wkitty42 but rather a desire not to let not mumble flow .. but I could be wrong
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGCom 3.5 & Openradar

Postby mickybadia » Mon Jun 29, 2015 10:29 am

myself wrote in Wed Jun 24, 2015 12:57 pm:I suspect the problem is neither ATC-pie nor OpenRadar, nor the FGCom server alone, and rather involves new FGCom 3.4 client

This might actually be wrong. Given the huge list of supposedly active connections on fgcom.flightgear.org, the server might be failing to shut down a few things properly, possibly resulting in sending stuff out to sane clients that are simply woken up while they should not be receiving anything. Not sure.

@Kévin: Have you changed something on the server's side recently? The live connection list has been suspicious for a few days, but I feel it has not always been since it was up.
Last edited by mickybadia on Tue Jun 30, 2015 4:15 pm, edited 1 time in total.
mickybadia
 
Posts: 475
Joined: Tue Sep 24, 2013 10:12 am

Re: FGCom 3.5 & Openradar

Postby KL-666 » Mon Jun 29, 2015 10:46 am

Yes, funny modification on fgcom.flightgear.org.

- users on the list are not in multiplayer
- multiplayers are not in the list

Either that list shows bogus data, or it shows users that have fgcom on, but never use multiplayer.

Kind regards, Vincent
KL-666
 
Posts: 781
Joined: Sat Jan 19, 2013 2:32 pm

Re: FGCom 3.5 & Openradar

Postby daweed » Mon Jun 29, 2015 3:46 pm

wkitty42 wrote in Fri Jun 26, 2015 2:34 am:seems to me that some are willing to try to get FGCOM fixed instead of using some 3rd party method... personally speaking, mumble will not pass by my firewall or security rules...


@wktty42 : Sure, i d'like that FGCom to be fixe, because it should be the communication tools for evryone in FGWorld ...

Here some screeshot i made (as some seems to say that end user are complaining but don't give informations ...)

FG Version :
Image

FGCom Client Version
Image

OpenRadar FGCom Configuration
Image

FGCom Processes
Image

Top with FGCom Processes
Image
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGCom 3.5 & Openradar

Postby daweed » Mon Jun 29, 2015 3:52 pm

And i forgot ..

My configuration :

Linux Mint 17.1 (keep updated)
8Gb RAM (can see on Top)
Quad Core Processor AMD FX 4300 Black Edition (3.8 GHz)
Nvidia GT 9800 with Nvidia Drivers

If need more information, just ask :)

Best regards

And please just focus on the describe problem, this thread shoud not turn into a war between mumble and fgcom users.

Thanks again
Windows 10 / Linux Mint 20
AMD Ryzen 7 3700X |32 Go RAM GeForce RTX 3070 Ti 8 Go
FG Interface
Lyon Saint Exupery Scenery

ATC on LFLL on Friday 19:00 UTC => 22:00 UTC
daweed
 
Posts: 398
Joined: Thu Dec 11, 2014 11:45 am
Location: LFKP LFLL
Callsign: daweed
OS: Linux Mint 20

Re: FGCom 3.5 & Openradar

Postby vector » Mon Jun 29, 2015 4:20 pm

Agreed, we all like mumble too but that was not the topic (how about starting a mumble topic?). There is a high load issue with fgcom and flooding traffic from the server that must have some cause. Is there a way to ping Kevin from this forum so he can have a look on the server side?
vector
 
Posts: 24
Joined: Wed Apr 17, 2013 8:40 am
Location: FR
Version: git
OS: Archlinux

Re: FGCom 3.5 & Openradar

Postby Saga » Tue Jun 30, 2015 3:29 pm

Sorry I was quite busy last few weeks.

The big amount of users displayed on the status page is caused by non-intercepted disconnections by the web site. This is not related to the FGCom server. From FGCom server side, connections to clients are well released.
I still didn't find a way to reproduce the problem, sometimes clients are removed from the database, sometimes not. But anyway FGCom is the more important.

I launched some tests, and indeed the fgcom client seems to use the entire core but only in a specific case. It seems to occur only when the frequency is not specified. If I type a wrong server address, the CPU usage is still at 100%.

100% CPU usage:
Code: Select all
fgcom --airport=KSFO --server=fgcom.flightgear.org
fgcom --airport=KSFO --server=fgcom.flightgear.orgg

Normal (~2% on my PC):
Code: Select all
fgcom --airport=KSFO --frequency=120.5 --server=fgcom.flightgear.orgg
fgcom --airport=KSFO --frequency=120.5 --server=fgcom.flightgear.org

So I'd say this problem is client side.

And indeed, datas are still received from the server to the fgcom client when nobody is speaking, but according to wireshark and jnettop, the traffic usage is ~3Kbps without ACK. It's not big but I can see if it's related to the Asterisk's ConfBridge.

And I feel sorry for these FGCom trust issues.
Host and maintainer of fgcom.flightgear.org.
Saga
 
Posts: 69
Joined: Tue Mar 04, 2014 3:52 pm
Location: Loire-Atlantique, France
Callsign: F-G0z
Version: Git next
OS: Win7, ArchLinux x64

Next

Return to FGCom

Who is online

Users browsing this forum: No registered users and 4 guests