Latency and simulation of a high speed limit

Hello,

I have installed softperfect with a trial license. My requirement is to simulate the following:
1. bandwidth of 25 Mbps and a latency of 125ms.
2. bandwidth of 27 Mbps and latency of 80ms.

I added a speed limit with value 25000000 and set a fixed latency of 60ms. After that when I run a download test to check the bandwidth, I just get around 6 Mbps and latency 80ms. I also tried many other combinations by changing the speed limit. However I could never achieve 25 Mbps. I could get it only when I disabled the latency. Can you please let me know how to go about. Is there any limitation that with a trial license it is not possible to achieve this?

Regards,
Rajeev

It sounds about right as latency directly affects TCP throughput. Please see this article.

The author found the following correlations (round-trip latency/max TCP throughput):

0ms   93.5 Mbps
30ms  16.2 Mbps
60ms  8.07 Mbps
90ms  5.32 Mbps

The article "How to calculate TCP throughput for long distance links" provides a few formulas and mentions similar numbers.

Hello Andrew,

Thanks a lot for your response.

We have seen that in a LTE network, the latency was around 125ms and the bandwidth we could achieve was 25Mbps. So, the softperfect software should allow us to simulate that condition. Infact, with chrome throttling options, we were able to do it. Please find the attachments in the URL
Link to Share: https://mdocs.sap.com/mcm/public/v1/open?shr=3oSXDiabGaM8koxF1WO50owERC1FzL6_C5FSpMgzql0
Even in the documents that you have pointed, we see that TCP increases the window size when it receives the acknowledgement of the packets that reached the destination. So could you please let us know how to simulate this using softperfect.

Regards,
Rajeev

My best guess is that it's not related to the Connection Emulator itself - we just introduce a simple delay to simulate latency. Perhaps the systems for some reason don't increase TCP window size further. I'd recommend to record a session with a packet sniffer like Wireshark or with the Connection Emulator's capture and see what TCP window size the two systems agree upon:



Basically you need to check whether both hosts exchange the Window Scale option in their SYN packets. If they don't, the means the maximum TCP window size will be 64K, which will result in the reduced transmission speed.

As to Chrome, its throttling mechanism appears to be flawed, e.g. they attempt to simulate latency and bandwidth limits at the application layer, where it should have been done at the packet level. There is also a long-standing bug where these settings have no effect on web-sockets.

Unfortunately I cannot access your test, but the well-known SpeedTest.net shows that Chrome's throttling simply doesn't work: