Server uplink: Mbps, unmetered and traffic limits

A server uplink is described by two numbers: the port speed in Mbps or Gbps, and the rule for counting volume. Unmetered means volume is not counted at all and only port speed limits you. A metered plan gives you a monthly allowance in terabytes, after which the speed is throttled or the overage is billed. Choose based on which one you hit first: peak speed or total volume.

Unmetered caps speed only; metered caps volume (here that is only Dedicated Start US: 1 Gbps with 30 TB).
A 1 Gbps port saturated for 30 days moves roughly 324 TB, which almost nobody actually uses.
A 30 TB monthly cap is equivalent to about 92 Mbps sustained around the clock.
Port speed is not the speed to a given client: routing, TCP window and packet loss matter more than the plan number.

What unmetered means and what a TB cap means

Unmetered (sometimes written unlimited) is about volume, not speed. A 100 Mbps unmetered port lets you push traffic around the clock, but never faster than 100 Mbps. A metered plan is the opposite: higher speed, with a fixed amount you may transfer per month.

Plan	Location	Uplink	Volume accounting	Price
Dedicated Start DE	Germany	100 Mbps	unmetered	$49
Dedicated Pro DE	Germany	1 Gbps	unmetered	$99
Dedicated Start US	USA	1 Gbps	30 TB per month	$59
Dedicated Pro US	USA	1 Gbps	unmetered	$89
Dedicated Enterprise US	USA	1 Gbps	unmetered	$149
Dedicated Start FR	France	500 Mbps	unmetered	$55
Dedicated Pro FR	France	1 Gbps	unmetered	$95

Location affects more than the price of the uplink; it also shapes the routes to your audience. The sites are compared in the article on choosing a server location.

Converting Mbps into terabytes

The arithmetic is simple: divide the speed by 8 to get megabytes per second, then multiply by the 2,592,000 seconds in 30 days.

100 Mbps is 12.5 MB/s, about 32 TB a month at full load.
500 Mbps is 62.5 MB/s, about 162 TB a month.
1 Gbps is 125 MB/s, about 324 TB a month.

The reverse calculation is more useful. The 30 TB cap on Dedicated Start US works out to 92 Mbps if you push a flat stream for 30 days. Real traffic is never flat: a daytime peak runs three times the night-time floor, so at a 92 Mbps daily average your peaks reach 250-300 Mbps, which makes the 1 Gbps port a requirement rather than headroom.

How to measure real throughput

The number in the plan is the switch port speed. Any individual client will see less because of routing, packet loss and TCP window size. Measure between the two points you actually care about.

# install
apt-get install -y iperf3 || dnf install -y iperf3

# on the receiving server: daemon in the background, log to a file
iperf3 -s -D > /var/log/iperf3.log 2>&1

# from the second machine: 10 streams, 30 seconds, both directions
iperf3 -c 203.0.113.10 -P 10 -t 30
iperf3 -c 203.0.113.10 -P 10 -t 30 -R

A single stream rarely fills a gigabit: over long routes TCP runs into window size and latency. That is why -P 10 is not cheating but the normal way to see the capacity of the link. A full methodology for measuring hardware and network together is in the article on benchmarking a dedicated server.

Counting traffic yourself with vnstat

vnstat reads interface counters and keeps history in its own database without capturing packets. It adds no measurable load and runs for years.

apt-get install -y vnstat || dnf install -y vnstat
systemctl enable --now vnstat

# bind it to the interface (newer versions do this automatically)
vnstat -i eth0

# monthly and daily summaries
vnstat -m
vnstat -d

# export to JSON for your monitoring stack
vnstat --json m > /root/traffic-monthly.json

What to do as you approach the cap

Do not cap the uplink with an iptables DROP rule keyed on a byte counter. That kind of "protection" tears connections apart mid-transfer, breaks downloads and TLS sessions, and the counter resets on reboot so the limit silently stops working. Limit the rate instead of cutting traffic: tc with an HTB discipline slows delivery while connections stay alive. To confirm the shaper works: tc -s qdisc show dev eth0 shows non-zero dropped counters and growing volume in the class, and a curl download of a large file returns the expected rate rather than zero.

# limit outbound interface rate to 200 Mbps
tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:10 htb rate 200mbit ceil 200mbit

# inspect the statistics and remove the limit
tc -s qdisc show dev eth0
tc qdisc del dev eth0 root

If traffic grows because of an attack rather than users, shaping will not help: it slows hostile packets and your own customers equally. Identifying the source and filtering it is covered in the article on DDoS protection for a dedicated server.

For projects with constant heavy delivery such as video, file mirrors and image distribution, take an unmetered plan from the start rather than a capped one. What exactly saturates the uplink when serving video is covered in the article on a server for video and streaming. The full list of uplinks per plan is on the dedicated servers page.

Key takeaways

Unmetered limits speed, metered limits volume; at ZevsHost only Dedicated Start US carries a TB cap.
1 Gbps saturated is about 324 TB over 30 days; a 30 TB cap equals a 92 Mbps average.
Measure with iperf3 using multiple streams in both directions, since one stream understates the result.
Near the cap, shape the rate with tc instead of dropping traffic outright.

Server uplink: Mbps, unmetered plans and traffic caps