When you think you are measuring the real speed of a 5G network, you are often measuring the limit of your own test server. This is the problem field measurement teams run into most often: the radio side is capable of 800 Mbps, but the report shows 240 Mbps, because the bottleneck is not in the network — it is at the server end of the measurement chain. With 5G entering commercial service in Türkiye on 1 April 2026, operator benchmarking campaigns, coverage validation and QoS reporting have grown quickly. This guide explains how FTP-based download and upload throughput tests should be designed, which KPIs belong in a report, and why the test server directly determines the quality of your measurement.
HTTP-based speed tests are widespread, but FTP retains its place in corporate benchmarking and regulatory reporting. The reason is simple: FTP is predictable. There is no caching layer, CDN steering, compression or adaptive bitrate on the server side to blur the result. You transfer a file of a defined size in a defined direction, and you measure how long it takes.
That determinism is what makes different operators and different measurement campaigns comparable. To compare at all, every component of the chain outside the network under test must remain fixed and unconstrained — and FTP achieves this with the fewest variables.
The reference framework for QoS measurement in mobile networks is the ETSI TS 102 250 series, which defines measurement end to end:
The critical clause from a test server perspective is this: the standard requires FTP measurement to be performed against a reference FTP server that supports the standard FTP commands, allows both active and passive mode data transfer, and applies no bandwidth limitation at application level. If there is a speed cap, per-user quota or connection limit on the server side, the measurement is invalid.
The standard also notes that throughput may be calculated with or without TCP retransmissions, and likewise using payload only or including transport protocol headers. If your report does not state which method was used, the numbers cannot be compared with anyone else's.
The maximum rate a single TCP stream can carry depends on window size and round-trip time. The bandwidth-delay product gives you this: BDP = throughput × RTT. In a measurement targeting 1 Gbps with an RTT of 30 ms, a single stream needs a window of roughly 3.75 MB to fill the link.
If window scaling is disabled, the TCP window is capped at 64 KB and a single stream stalls at a few Mbps at that same RTT. This is why net.core.rmem_max, net.core.wmem_max and net.ipv4.tcp_rmem / tcp_wmem must be tuned on the test server to match your target throughput.
A single TCP stream continually backs off due to congestion control in a lossy radio environment. Benchmarking campaigns therefore usually use parallel streams. But the stream count must be stated in the report: 300 Mbps measured with 1 stream is not the same result as 300 Mbps measured with 8. If you intend to compare, use an identical profile for every operator.
Storage is the bottleneck most often overlooked in high-speed testing. Sustained transfer at 1 Gbps means reading roughly 125 MB per second. On spinning disks or shared storage this alone becomes the ceiling. Keeping test files on NVMe — and where possible sizing them to fit the operating system cache — makes the measurement independent of storage.
Plain FTP places little load on the CPU, but if you use FTPS the encryption cost enters the picture and you can hit a single-core limit at high rates. If the purpose of the measurement is to evaluate the network, you need to be certain encryption is not shaping the result.
The location of the test server determines what you are actually measuring. If the server sits abroad, your report reflects the operator's international transit quality rather than its radio access network. When coverage and radio performance are under assessment, the server needs to be in the country being measured — ideally at a point where operators peer heavily.
In Türkiye, commercial 5G services began on 1 April 2026 in Istanbul, Ankara, Izmir, Bursa, Kocaeli and Konya, with coverage expanding in stages. For drive tests in these cities, an Istanbul-located test server keeps RTT in the single-digit or low double-digit millisecond range and largely eliminates artificial BDP-driven limits. If you are unsure which server type suits you, our VPS versus VDS comparison is a useful starting point.
In 5G, uplink throughput sits well below downlink because of TDD time-division and device power limits. In upload tests, the server's write performance and inbound connection limits become a bottleneck more readily than in downlink tests. If you use passive mode FTP, make sure a sufficiently wide data port range is open on the firewall.
For a QoS report to be comparable, it needs more than a raw speed figure:
The three things asked most often when providing infrastructure for measurement campaigns are location, capacity and stability. Our AMD Ryzen 9 9950X based Turkey-location VDS options run in Istanbul with DDR5 memory and NVMe M2 SSD storage on 1 Gbps unlimited traffic. High single-core performance keeps the server from becoming the bottleneck in scenarios involving encrypted transfer or many concurrent sessions. Our network infrastructure is DDoS-protected, which matters for long-running campaigns conducted over a public IP, so that testing is not interrupted by external noise.
If your total requirement exceeds 1 Gbps, or you need isolated, non-shared hardware, a separate configuration can be planned around port capacity and topology through our dedicated server solutions. Get in touch to work out the right setup for the scale of your campaign.
FTP has no caching, CDN steering or compression layers to alter the result. That determinism is what allows different operators and different campaigns to be compared with each other.
Both are valid, but they measure different things. What matters is using the same profile for every operator and every measurement point, and stating the stream count in the report.
Record the server's CPU, disk and interface utilisation during the test. If any of them saturates on the server side, your figure reflects the server rather than the network. A wired test from a controlled reference point is also useful for comparison.
If you are assessing the radio access network, yes. A server abroad adds international transit latency and possible congestion to the result, meaning you measure external connectivity quality rather than the operator's radio performance.
In 5G, uplink capacity is substantially lower than downlink because of TDD time-division and the device's transmit power. This is expected — but you should also check server-side write performance and passive mode port range configuration.
Reporting only an average is misleading. Presenting the median alongside the 10th and 90th percentiles, the session success ratio and the radio context (RSRP, RSRQ, SINR) makes the report interpretable.
FTP-based throughput testing, when designed correctly, is one of the most repeatable ways to evaluate 5G network performance. But the validity of the measurement depends on the test server being transparent and unconstrained: no application-level rate limit, TCP buffers tuned to the target rate, storage that does not bottleneck, and a location inside the country being measured. The ETSI TS 102 250 series standardises both KPI definitions and measurement profiles so results remain comparable. Stream count, file size and calculation method must always be stated in the report.
We can plan the test server setup for your operator benchmarking and QoS reporting campaigns on Istanbul-located, DDoS-protected network infrastructure. Share the scale of your campaign and your target throughput figures and our 24/7 support team will work out a suitable configuration.
Turkey (Türkçe)
Worldwide (English)
