Sawtooth shaped download speed

[Gunnar]

Hi to everybody.

I had a very serious network issue after installing Ms Flight simulator, Nvidia Graphics Drivers, some MSI Motherboard Utilities.
My transfer speed was reduced from 500Mbit/s to 3 Mbit/s PER CONNECTION
This limitation only occurred on connections with high latency (200ms).

After struggling with my provider, with my Windows/Network/Router for weeks,
I discovered the TCP Optimizer a week ago and saw that my setting where really our of whack.

I choose "Optimal", hit Apply Changes and have been flying ever since.

I still have a problem on high latency connection;
I am downloading an 8GByte file daily from my own server on the other side of the world.
The download speed climbs to 500mb, then drops to 0, then climbs again, and drops and so on.
Interval length around 15 to 20 seconds.

I cant guarantee the problem is not on the router or server side, but my suspicions are my Windows 10 PC configuration.

My advertised speed is 500 down, 50 up.
When running speedtest i get 532 Mb Up, 53 Mb down. Latency 4ms
Internet provider is Antel (Ururugay) Fiber

Local PC has Intel Ethernet Controller I225-V
Windows 10 Pro, Version 21H1
Router Asus RT-AC67U

I have tried changing Congestion Control Provider from CUBIC to ctcp,
and changing TCP Window Auto-Tuning from Normal to experimental.
The latter possibly giving me improved throughput.


Analyzer:
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2021.05.31 12:36
IP address: 186.54.xx.xxx
Client OS/browser: Windows 10 (Chrome 89.0.4389.90)

TCP options string: 020405ac0103030e01010402
MSS: 1452
MTU: 1492
TCP Window: 262144 (not multiple of MSS)
RWIN Scaling: 14 bits (2^14=16384)
Unscaled RWIN : 16
Recommended RWINs: 63888, 127776, 255552, 511104, 1022208
BDP limit (200ms): 10486kbps (1311KBytes/s)
BDP limit (500ms): 4194kbps (524KBytes/s)
MTU Discovery: ON
TTL: 52
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)

Does anybody have ideas as to what is causing the transfer dropping to 0 every 15-20 seconds?

Regards,
Gunnar

[Philip]

The type of issue you describe sometimes is caused by too aggressive buffer settings, I would use try the "Normal" auto-tuning instead of "Experimental." As for the anti-congestion algorithm, Cubic should perform slightly better than CTCP for pure throughput, CTCP is a bit better for VoIP/gaming.

What sometimes happens is that routers in the middle of the connection can't hold high buffers for your connection (they have to handle thousands of different connections) and they drop/delay some packets, or just delay acknowledgement of received packets, causing your end to retransmit them and TCP enters recovery state (starts slow and builds up speed again). Newer anti-congestion algorithms (CTCP/CUBIC) cope better with such events, with Cubic being slightly better for file transfers.

[Gunnar]

Hi Philip,
Thank you for reply, and thank you very much for that brilliant piece of software, the TCP Optimizer!
As for your analysis, I think you are spot on with "and TCP enters recovery state (starts slow and builds up speed again)"
I have tried Normal and Experimental, with the latter possibly giving a slight improvement overall.
If there is nothing more I can do on my Windows machine, do you think there could be any settings on my local router (I cant find any interesting settings on it (Asus RT-AC67U)
Alternatively, I am also in control of the server giving me download problems. Could the server be causing the buffering issues ? (Windows Server 2019, 1Gb connection)

Gunnar

[Philip]

It is likely not at your location.

Asus RT series are good routers with plenty of processing power and RAM, but yes, in general any router can get bogged down with gigabit speed transfers.
You can try turning off "AiProtection" (Trend Micro), QoS, and any other unnecessary services, it can be temporarily to see if it makes a difference. Also check the CPU load in the router while transfers are in progress (under General > Network Map > Status). Make sure you use gigabit rated Ethernet cables and keep the router/cables away from possible sources of electromagnetic interference (EMI).