Mumble

[NiteShade]

Yep, finally tried it out last night - sounds great with ppl using a decent mic/setup!

[pmurgs]

Nvm, Nomad and Hubris helped me find how to set my push to talk key.

[Megageth]

Go to Configure>Shortcuts>Add
Then select "Push to talk" from the drop down of the Function column. Go to the right column to define a key, then Apply.
Pic below.

[Skouperd]

Hi guys, sorry for raising this topic but perhaps somebody here had the some problem and managed to solve it. It is a network related question. Whenever I use Mumble, my ingame latency shots through the roof. Playing without mumble result in very low latency, but playing with mumble result in 200+ latency.

The way I understand Mumble, and please correct me if I am wrong, is that it will transmit audio packets (send or receive) every x-ms (assume 10ms which I think is the default). So what that means is in 1 second it transmit a 100 packets thereby causing latency. Teamspeak and the likes have a much larger buffer and will only transmit say every 50ms (thus only 20 packets per second) meaning not as much an impact on latency.

From my understanding, that is the very reason why we moved to Mumble as the delay in TeamSpeak is too much.

I am just curious as to the following:
1. What settings are you guys using in terms of packets / second (or latency before sending packets)
2. Does anybody else have this problem

[SlipperyDuck]

no problem from my end.

Audio packets are generally only 100byte out of the 1500byte size packet anyway so even though they send a lot of packets, the interpolation between a voice packet and a data packet which is typically 1500bytes or so in size makes it almost negligible.

the only time i can forsee a problem, is when you have a network with large amounts of traffic and thereby large amounts of packet data being switched through a common port/trunk, most simple home networks have none of these problems.

bottom line - no impact for me and my ping even when there are multiple people talking and I'm currently gaming.

[Megageth]

Ya Skoups, I briefly checked everyone's ping when I watched a baggers prac and they were all (whilst on Mumble) in the 10ms-80ms range. Must be something particular to your network. I seem to remember you saying that you don't use Anti Virus on your gaming machine so I guess thats not an issue... I don't know enough to post a solution.

[Stu]

Is is not your firewall system that is 'sniffing' the incoming and outgoing packets? could cause an increase in latency.

[Skouperd]

Lee, help me if I am wrong. My understanding is the problem is not so much the "size" of the packet, but the number of packets it needs to send and route. You can encapsulate data into a single packet (being the norm of ~1500bytes) and the router will just route that single packet (read the header, process it, and route it). If we suddenly send 100 packets (of say 15bytes each) then the router now need to route each packet individually and that may saturate something on the network.

I am not a network expert, so I may be completely wrong in my understanding on the above.

...most simple home networks...

and that might be the problem.... unfortunately, my network might be seen as slightly more complicated than a simple home normal network...

I've been redoing my network the last two weeks or so, well after I’ve started experiencing / noticing the problem, I decided now is as good as ever to redo it. I effectively retested each network point on my network, making new patch cables for wall to pc, and new patch cables from panels to switches, rewiring all my racks, and reconfiguring all my firewalls / routers / switches from scratch. (Upgraded to the latest ROS, and just redone everything). Bear in mind the problem existed before I embarked on this very adventurous journey.

This is a diagram of my current network



Allow me to explain.

I have 4 different subnets
192.168.0.0/24 which is all my LAN traffic
192.168.121.0/29 which is all my Internet routing
10.0.0.0/24 which is all my Wireless traffic
172.18.89.15/28 which is all my CT-WUG traffic

Any subnet outside of 192.168.0.0/24 range first need to pass a dedicated firewall specific to that subnet and point of entry. Only once it gains access to the 192.168.0.0/24 range can it be routed outside of to the network, which also sits on its own subnet, being 192.168.121.x.

My gaming PC sits in the games room, and connects to the switch located in the server room, which in turn is connected to a switch inside the house (using on a 2Gb link aggregated backbone). The house switch is connected to a Mikrotik 751 AP / Firewall / Router that will route traffic to / from the internet. The only way for traffic to reach the internet is through that router as it is physically the only connection to the ADSL router). The Telkom ADSL router maintain the Telkom link and has been programmed to forward any incoming requests from the net onto RB1.

RB1 is connected to the house-switch with only a 100Mb connection (given that the ADSL is only 4Mb it should be fine). In theory I could saturate the 100Mb connection by doing something stupid on the internal network, but the way the network is setup is that only traffic outside the 192.168.0.0 range will ever go to RB1, all internal 192.168.0.0 traffic otherwise will just go directly to the target. The utilisation on that 100Mb connection is very low with only some broadcasting packets reaching it (which is blocked by the RB before it gets forwarded on to the ADSL router). Even when I am downloading from CTWUG, non of the CTWUG traffic will even touch that router.

Lee, if you think you can spot a potential flaw, or link that may be saturated, somewhere in this setup, please let me know. Otherwise, I will continue to look at some of Mumble’s settings.

BTW, I only picked up yesterday evening that mumble may be causing the problems and haven’t investigated it fully as yet. (i.e. packet sniffing etc.)

[SlipperyDuck]

Sounds to me like a packets per second (Denial Of Service Attack) flood on the 100M off PROLINE HP to the wiresless / Internet throught the Master Gateway 192.168.0.1

Most likely too many packets and not enough processing power on the master gateway router.

[Skouperd]

Thanks Lee, I've enabled CPU monitoring on RB1 (the master gateway) yesterday evening and will be able to pull the stats tonight. Will have a look at it, and also see exactly what packets is killing her.