For an operator to credibly tell a subscriber "you have 1 Gbps", the measurement has to be taken from the right place: the closer the measurement node sits to the access network, the more the result reflects the subscriber's actual line — and the further away it sits, the more you are measuring transit and peering rather than the line itself. This is why operators, measurement and reporting companies and enterprise network teams run their own speed measurement nodes. This guide covers what a measurement node does, which metrics a defensible measurement requires, why a single TCP stream cannot fill a gigabit link, and what to look for when building the infrastructure.
A measurement node is a server with high-capacity connectivity, positioned opposite the subscriber or test client. The client sends and receives data against it to measure download speed, upload speed, latency and jitter.
The critical point: a measurement result reflects the weakest link between client and server. Even if the subscriber's line is 1 Gbps, if the measurement node sits in another country or is reached over a circuitous transit path, what you measured is that path's capacity — not the subscriber's access speed.
Running your own node has three concrete benefits:
A "speed test" produces one number, but several distinct quantities sit behind it, and conflating them makes the measurement misleading.
How TCP-based measurement should be conducted is framed by RFC 6349. It does not stop at "how many Mbps" — it defines three additional metrics:
RFC 6349 also defines the test order: determine path MTU first, then baseline RTT and capacity during off-peak hours, then run throughput tests in both directions with properly sized buffers. Skip that order and the number you get is not reproducible.
The classic field scenario: the link is 1 Gbps, the test shows 200 Mbps, and everyone blames the network. The cause is usually TCP's own physics.
The maximum a single TCP stream can carry is bounded by:
max throughput = window size / RTT
The window size you need is the BDP (Bandwidth-Delay Product), calculated as bandwidth × RTT. RFC 6349 is explicit: send and receive socket buffers should be equal to or greater than the BDP.
A concrete example: on a 100 Mbps path with 5 ms RTT, a 16 KB window yields only 25.6 Mbps. The link is healthy; the window is the constraint.
On high-capacity, long-distance paths the numbers get more dramatic:
Turkey (Türkçe)
Worldwide (English)
iperf3 -c server -w 12M -P 4iperf3 -c server -w 100M -P 4Parallel streams (-P) solve the same problem differently: four streams, even at 64 KB windows each, keep 256 KB of data in flight. This is also a useful diagnostic fork:
One final warning: the operating system may silently cap the buffer size you requested. Always check the "socket buffer size" line in iperf3's output.
However powerful the measurement node's hardware, what determines the result is the path to it. Two concepts separate here: transit is buying reach to the whole internet from an upstream provider; peering is two networks exchanging their own traffic directly, usually across an internet exchange point (IXP).
Peering's value for measurement is fewer hops and a shorter path. Traffic from a domestic subscriber to a domestic measurement node, handed over directly at an IXP, sees lower latency and is insulated from transit congestion.
Turkey's infrastructure is mature in this respect. According to Internet Society Pulse data, Turkey has five active internet exchange points with 95 members in total — four in Istanbul and one in Ankara. 64% of networks are either IXP members themselves or customers of an IXP member, and 66% of the 1,000 most-visited websites in Turkey are reachable through an in-country server or cache.
The practical consequence: place your measurement node domestically on well-peered infrastructure and what you measure is genuinely access-network performance. Measure against an overseas node and international capacity and transit conditions enter the result.
There is no single correct tool — it depends on the purpose, and most operators use several together.
The interface subscribers already know and reach for on their own. Running your own node keeps their tests terminating inside your network. Valuable for brand perception and complaint handling, though you have limited control over the methodology.
An open-source measurement platform. ndt7 uses TCP BBR where available and collects kernel-level statistics through TCP_INFO: throughput, RTT, packet loss and the congestion control algorithm in use. The right choice when you need visibility into how the measurement was made.
The reference tool. Not for subscriber-facing tests but for engineering verification: window size, parallel stream count, TCP/UDP choice and duration are entirely under your control. It is the standard for acceptance testing and fault diagnosis.
Preferred particularly for mobile network measurement, because the test client behaves like a standard application and field teams can measure without installing specialised tooling. We covered this approach in detail in our guide on the FTP test server for mobile network measurement.
Unlike fixed-line measurement, mobile testing adds location and time as dimensions. For measurements taken in the same cell, at the same hour, across different operators to be comparable, the server side must stay invariant: same server, same file size, same protocol, same capacity.
If the server side is not constant, you cannot tell whether an observed difference is an operator difference or server load. That is why, for field measurement companies, the measurement server's consistency matters as much as its capacity — it must not be under other load at the moment of measurement.
On 5G the picture becomes even more sensitive; at high throughput, a single stream with default buffer settings runs out of headroom quickly. We covered that scenario in our guide on FTP-based throughput testing and QoS reporting on 5G networks.
A measurement server calls for a different profile than a normal web server. In priority order:
Measurement is as much a documentation activity as a technical one. Turkey's regulator (BTK) approaches broadband transparency by requiring that committed connection speed and actual speed information, fair usage policy application and service quality parameters are disclosed to subscribers accurately and kept current.
For whoever builds the measurement infrastructure, that means the data produced must be methodologically documented, reproducible and archivable. A report is defensible only if it records which server, which protocol, which window size, what time and which location the measurement used.
Practical recommendation: store server identity, test file size, protocol, parallel stream count, window size, client location, timestamp and raw results together with every measurement record. Producing aggregate statistics later is easy; recovering missing metadata afterwards is impossible.
Nubitro offers servers configured for the profile telecommunications and measurement companies need: Istanbul, Turkey location, 1 Gbps unmetered traffic, NVMe M.2 SSD storage and AMD Ryzen 9 9950X processors. Because resources are assigned through hardware partitioning, there is no fluctuation from neighbour load during a measurement — the single most critical property for a measurement server.
Configurations scale from 2 cores / 4 GB RAM up to 12 cores / 64 GB RAM with 180 GB NVMe. For setups needing higher capacity, custom port speeds or multiple IPs, consider our dedicated servers.
When planning your measurement infrastructure, our VDS buying guide helps with sizing and location, and our new server security checklist covers configuration after handover.
Target at least double the maximum subscriber speed you intend to verify. A 1 Gbps port is marginal for validating 1 Gbps subscriber lines and insufficient if multiple tests run concurrently. Choose unmetered traffic rather than a monthly cap.
A single TCP stream's speed is bounded by window size divided by RTT. If the window is below BDP, the stream spends time waiting for acknowledgements. The fix is either raising the window to BDP or using parallel streams.
They measure different things. Ookla measures application-layer experience over multiple connections; iperf3 measures raw transfer capacity with parameters you set. The difference is methodology, not error — always state which tool a report used.
On a shared-resource virtual server, yes — neighbour load during the measurement distorts the result. With reserved resources it does not. Verify genuine dedication by checking that %st (steal time) in top output stays near zero.
Large enough for the transfer to move past TCP slow start and reach equilibrium. On high-speed links, small files measure only slow start and understate real capacity. Duration-based testing (30 seconds, for example) is also a sound approach.
At least as long as your reporting obligations and customer contracts require; in practice, keeping raw data together with its metadata is your only defence against a later dispute. Consult a legal advisor on retention periods and personal data implications.