I am about to change Dedicated Server providers. My current provider says the uplink is 500M. The (potential) new host offers by default a 100M uplink and charges an extra $100/Month for a Gigabit uplink instead. (nothing in between).

My overall bandwidth usage is around 80-100 Gig / Month (as reported by WHM) This seems pretty low on average, but does not help me with the peaks.

How can I determine my peak bandwith over a few hours or days?

  • 2
    possible duplicate of Can you help me with my capacity planning? – Jacob May 19 '14 at 17:36
  • 1
    Actually no. This is quite a good technical question as can be seen in my answer. – TomTom May 19 '14 at 19:05
  • @Jacob, The suggested duplicate is a very vague "is it (will it be) good enough" type of question. I asked my question looking for how to find the statistics I need to make an informed decision. TomTom's answer and comment pointed me in the right direction. – TecBrat May 19 '14 at 19:55
  • @TecBrat Those statistics won't help you. Knowing how much bandwidth you used won't tell you how much you needed. (For example, your backups might spike to a very high value just because there's lots of bandwidth between the backup machine and this machine. But the backup performance might be perfectly adequate with 1/10th the bandwidth.) You need to figure out what you need, not what you're using. – David Schwartz May 20 '14 at 5:02
  • @DavidSchwartz, thank you for your feedback. I'll take that into consideration. I'm more likely to find that even at peak, I'm not using all I have, and therefor these tests should be "good enough". Is that logic sound? – TecBrat May 20 '14 at 13:30

Run a program counting traffivc in minute intervals, visualize it. Any firewall should be able to do that. This shows you utilized bandwidth and that tells you all you need to know.

MOnitorix should b able to do that on Linux.


  • I ran iftop (reference here) for a while and the highest spike I have seen after several minutes is around 17Mb (It seems that the small "b" means "bits" rather than "bytes" ) So, unless there's a HUGE difference when the bots come a-calling, I think I'll be fine. – TecBrat May 19 '14 at 18:50
  • Now get professional and run it for a week. A couple of minutes is useless unless you can confirm it is at your prime time - traffic varies widely by time of the day. But this way isa good way to go with it, because with this you can PLAN, not guess. – TomTom May 19 '14 at 19:04
  • Somewhere in my searching today I found iptraf and installed it with yum (CentOS). I have it logging and running in the background. I'll check it tomorrow and see what it logs. I'm accepting this answer even thought I did not try "Monitorix" because it seems like the same concept. – TecBrat May 19 '14 at 20:55

Just the bandwidth usage is not really enough to decide whether 100M is enough for you. Do you serve large files? Video streams? Gaming server? Many simultaneous users?

A large uplink speed is useful if you serve large files, or many users at the same time. Since you have to ask, I'd say the chance that 100M is enough for you is pretty high.

  • I could add this as an edit, but I think it makes sense as a comment here: Other than getting the new server at 100M and upgrading if I need it, How might I benchmark to know if I need a faster uplink? – TecBrat May 19 '14 at 17:41
  • Run a program counting traffivc in minute intervals, visualize it. Any firewall should be able to do that. This shows you utilized bandwidth and that tells you all you need to know. – TomTom May 19 '14 at 17:43
  • You can try downloading a large file from your server, and see how fast it goes. The theoretical maximum for 100mbit is 12MB/sec and the maximum for 500mbit is thus 60MB/sec. I am not familiar with WHM, but possibly it has some statistics you can use to base your choice on? – jornane May 19 '14 at 17:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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