TCP speed tester algorithm question

Question

I am working in an ISP company. We are developing a speed tester for our customers, but running into some issues with TCP speed testing.

One client had a total time duration on 102 seconds transferring 100 MB with a packet size of 8192. 100.000.000 / 8192 = 12.202 packets. If the client sends an ACK every other packet that seems like a lot of time just transmitting the ACKs. Say the client sends 6000 ACKs and the RTT is 15ms - that's 6000 * 7.5 = 45.000ms = 45 seconds just for the ACKs?

If I use this calculation for Mbit/s:

(((sizeof_download_in_bytes / durationinseconds) /1000) /1000) * 8 = Mbp/s

I will get the result in Mbp/s, but then the higher the TTL is between the sender and the client the lower the Mbp/s speed will become.

To simulate that the user is closer to the server, would it be "legal" to remove the ACK response time in the final result on the Mbp/s? This would be like simulating the enduser is close to the server?

So I would display this calculation to the end user:

(((sizeof_download_in_bytes / (durationinseconds - 45sec)) /1000)/1000) * 8 = Mbp/s 

Is that valid?

Answer 1

The problem here is that the RTT is too large so that not the entire bandwidth is used. You might want to increase the TCP window size, which can be done on a per-socket basis for testing purposes, as well as system-wide.

As a customer, I'd consider it a great service if a speed test program were to notify me of suboptimal system settings and offer me an option to correct them.

If TCP window settings are correct, RTT should not matter in a TCP speed test, unless you are losing a significant number of packets (but after all this is what you want to detect in the first place).

Answer 2

TCP utilizes window flow control and normally do not wait for ACKs before sending next frame. ACKs go simultaneously with data frames and do not require any extra wall clock time. Any recent TCP implementation can handle such RTT and bitrate without speed loss.

So correct calculation is number 1.

Also, are you sure your network really have 8192 MTU from customer's PC to your test server? It's quite probable somewhere Ethernet segment with 1500 MTU exists and your 8192 bytes send buffers are being split by TCP stack to standard 1500 byte TCP segments.

And finally, there is 1024 bytes in kilobyte and 1024 kilobytes in megabyte.