01
Build a traffic profile from observed intervals
Collect ingress and egress separately for at least one representative business cycle, retaining hourly or finer intervals as well as daily totals. Mark backups, releases, cache fills, replication, abuse events and one-off migrations so they are not mistaken for normal demand. A total alone hides whether the workload is a steady stream, short bursts or a few large transfer windows.
Use the same units throughout. Convert provider allowances and application measurements to bytes or decimal gigabytes before comparison, and state whether both directions are billed. If a contract uses a percentile method, obtain its exact sampling, direction and discard rules rather than assuming that every 95th-percentile product is calculated identically.
02
Measure the path, not only the interface
Run throughput tests only between systems you control or are authorized to test, and coordinate sustained high-rate tests with the relevant operator. iperf3 needs a client and server and can measure TCP, UDP or SCTP. Record endpoint hardware, direction, protocol, duration, stream count, time, route and result so a later test is comparable.
Start with baseline round-trip time, loss and path MTU, then compare a single TCP connection with the concurrency the application really uses. RFC 6349 explains why bottleneck bandwidth, round-trip time, receive window and path MTU affect TCP throughput. CPU limits, encryption, disk I/O and the remote peer can also cap a result. A 10 Gbps port is therefore a local ceiling, not proof of 10 Gbps application goodput to every destination.
03
Normalize the bill before comparing plans
Represent the metered option as fixed service cost plus billable transfer beyond any included allowance, then add public addresses, security services or committed-port charges that the invoice treats separately. Represent the unmetered option with its fixed term price and any required port upgrade. Keep ingress and egress variables separate until the contract confirms how they are charged.
Do not convert the theoretical continuous port maximum into expected monthly traffic. Instead, replay low, expected and high profiles from measured data. Unmetered service is valuable when it removes a volatile transfer line item; it does not remove the physical port, routing conditions, abuse controls or acceptable-use policy.
Normalize the bill before comparing plans| Scenario input | Low case | Expected case | High case |
|---|
| Billable egress | Quiet observed cycle | Representative cycle | Migration or peak cycle |
|---|
| Required application rate | Normal background | Busy interval | Recovery or release window |
|---|
| Evaluation | Minimum invoice | Operating baseline | Budget and capacity exposure |
|---|
04
Check policy and make results repeatable
Before ordering, confirm port rate, whether it is dedicated or shared, transfer accounting, overage behaviour, filtering, traffic restrictions and upgrade procedure. Tungsto catalogue pages describe included unmetered ports, but they do not guarantee a particular end-to-end route or application result.
The expected deliverable is a traffic profile, test record and cost worksheet with the contract assumptions attached. Repeat measurements after deployment at comparable times. Investigate changes in route, loss, latency, host load and peer capacity before concluding that the billing model caused a throughput change.
Direct answers
Questions about this guide
Does unmetered bandwidth mean unlimited speed?
No. It removes a transfer counter under the service terms. The port rate, protocol overhead, route, congestion, source and destination systems still bound observed throughput.
Is one iperf3 result enough to size a server?
No. It measures a defined path and test condition. Repeat authorized tests by direction and time, preserve the parameters, and compare them with application telemetry and the destinations users actually reach.