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?
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).