Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am wondering how much bandwidth does a Mumble server use in the span on a month. I have a dedicated Linux server with 10,000GB bandwidth/month.

In their FAQ they have this formula and information.

Worst case scenario: Number of users × Number of talking users × 133,6 kbit/s. With less aggressive quality settings, it's ~60 kbit/s, and the bare minimum is 17.4kbit/s. Note that Mumble is geared towards social gaming; its quality enables people to talk naturally to each other instead of just barking short commands, so the amount of "users talking at the same time" can be somewhat higher than expected. This means that a server with 20 players and 2 players talking at once requires 1-3 Mbit/s, depending on quality settings. In the server's .ini file, you can specify the maximum allowed bitrate for users as well as the maximum number of clients to allow.

But I am not sure how to calculate the monthly based on that formula. Say I use there example on the high end and use 3Mbit/s and basing it on 100Mbps = 12MB/s that would mean that I use 1.296GB/hour which means about 31.1GB/day. So monthly it would use 933.12GB.

That may be right, not 100% sure on my calculations, but it doesn't seem like 1 server should be using that much bandwidth (granted that requires 20 people in there with 2 people talking at all times).

Does this seem right? or am I missing something? Can anyone with some experience doing this kind of thing give me some insight.

Thank you

share|improve this question
The numbers seem right. Keep in mind that it seems very unlikely that you would have a continuous load during the entire day. So if your server is for a group of people from the US only, you probably will only see activity during a 8-12 hour window, and the rest of the day the server will be idle. – Zoredache Jan 24 '11 at 17:27
I don't understand your "3Mbps and basing it on 100Mbps" comments. How many users and talking users do you expect? How many hours per day are your users online? – Alex Holst Jan 24 '11 at 17:28
@Alex Holst its not "3Mbps and basing it on 100Mbps" its "basing it on 100Mbps = 12MB/s" and I was just looking for an average, I'm trying to figure out how many murmur servers I can have up per linux server if each server has 10,000GB bandwidth available to it. – Latency Jan 24 '11 at 18:55
@Zoredache that is true, so it would realistically be about half of that provided that it would be a continuous load for the active hours. I'm assuming that it takes little to no bandwidth when there is no one talking, but I am not sure of that. – Latency Jan 24 '11 at 18:55
up vote 2 down vote accepted

Those numbers seem sane, if (as people have commented) your numbers of users/talkers are relatively constant throughout the day -- or at least, average out at the figures you've started from. certainly gives a similar final answer, just under 1 TB per month.

I think the useful way to look at it is actually in reverse: in a month, you can use 10TB of transfer before risking overage charges or bandwidth throttling. 10TB per month is around 32Mbps -- so how many users/talkers would you need to average at to reach this? At maximum quality, this allows you something like 4 talkers and 60 users (32Mbps/133.6kbps ~= 240) averaged through the month before you max out your bandwidth -- assuming you don't need the allowance for anything else, of course! Obviously if you're already using half your transfer allowance for something else, you need to halve this...

Sounds to me like you've got plenty of bandwidth available for the task, even if the (worst case) estimates of what you'll use are a little alarming at first.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.