Official Mumble VoIP Forums

1.3.0 using huge amount of bandwidth/CPU cycles.

It crashed, it is bugged, ...
Reporting this so others may want to check. All the users on our server using 1.3.0 were using between 3 and 9 percent of CPU and between 2.2 and 4.6Mbps on their clients when connected. Immediately moving to 1.2.19 made the bandwidth and CPU usage go back to their usual "practically zero" status. Verified this myself and after restarting the instance some of the bandwidth used by 1.3 dropped to about half of the previous usage for some user but I'm still pulling 2.2Mbps if I turn on 1.3.

What could be causing this? Has the latest 1.3.0 version been hacked by coin miners or something?
Flexo wrote:
12 Jul 2018, 01:50
What could be causing this? Has the latest 1.3.0 version been hacked by coin miners or something?
lol no

What OS are we talking about? Is this a new issue in 1.3.0 or for a longer time/did you only test the most recent version?

Is this when talking or also when idle/nobody talking?
Well the issue started in the middle of the day. The server is on a Amazon AWS Linux server and all the clients were Windows 10. The bandwidth was 4+ Mbps for several users but the next day I checked and the bandwidth and CPU usage (as reported in Task Manager) was back down to normal on my install of 1.3.0.

I thought maybe an update was coming down for everyone but it shouldn't have been going on for hours like it did. Could the updating mechanism have a bug or have been hacked in some way? I don't know what went wrong and was hoping that someone else saw this happen so we could collaborate.
It’s not been hacked.

We had some server issues after a server upgrade on Saturday. I think I briefly remember some client issue when the services are down, where it would not handle that gracefully. But I don't remember specifics. If it was not while opening and using the public server list, I guess it would have to be the update check. But I would be pretty surprised if that spiked CPU and bandwidth noticeable. Especially if the issue occurs when the service is down, I don't see how that would, or should, increase bandwidth. There's not response to requests after all.