Geek Answers Handbook

TCP Speed ​​Test Algorithm Task

I work for a provider company. We are developing a speed tester for our clients, but we encounter some problems when testing TCP speed.

One client had a total time duration of 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 looks like a lot of time, it just sends the ACK. Say the client sends 6000 ACKs, and RTT - 15 ms - 6000 * 7.5 = 45.000ms = 45 seconds for ACK only?

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 the higher the TTL between the sender and the client, the lower the Mbp / s speed.

To simulate that the user is closer to the server, would it be “legal” to remove the ACK response time in the end result on Mbp / s? Will it be like an end-user simulation close to the server?

So, I would display this calculation for the end user:

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

It's right?

+6
c # tcp
source share
2 answers

The problem is that the RTT is too large to not use the entire bandwidth. You might want to increase the size of the TCP window that can be executed for each socket for testing purposes, as well as in the system-wide version .

As a client, I would consider this an excellent service if the speed check program should notify me of suboptimal system settings and offer me the opportunity to fix them.

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

+3
source share

TCP uses window flow control and usually does not wait for an ACK before sending the next frame. ACKs go simultaneously with data frames and do not require additional wall clock time. Any recent TCP implementation can handle such RTT and bitrate without loss of speed.

So, the correct calculation is number 1.

In addition, are you sure that your network really has 8192 MTUs from the PC client to your test server? It is likely that somewhere an Ethernet segment with 1500 MTU exists, and your send buffers of 8192 bytes are split over the TCP stack into standard TCP segments of 1500 bytes.

And finally, 1024 kilobytes in kilobytes and 1024 kilobytes in megabytes.

+3
source share

More articles:


All Articles