Zijn high latency links trager qua throughput?

[ETH0.1]

Ik heb iets raars en krijg er de vinger niet achter waar het probleem zit.

Ik heb een server staan aan de andere kant van de wereld, 200ms vertraging (ping), ik weet dat de uplinks van die server uiteindelijk 2x 200mbit zijn. in feite betekend dat, dat een enkele download nooit sneller kan zijn dan 200mbit/sec.

Nu is het rare dat de verbinding totaal niet snel is, een enkele download varieert ergens tussen de 20 en 40mbit/sec. Als ik echter 50 downloads tegelijkertijd aan zet trek ik de hele verbinding dicht en download ik met 400mbit/sec.

De 2x200mbit links worden niet volledig gebruikt, in het weekend zelfs bijna helemaal niet, de provider/datacenter daar zegt dat ze niets knijpen of dat er andere beperkingen zijn.

Kan het zo zijn dat een enkele download trager ik een ping heb van 200ms of staat dat los van elkaar?

[computerjunky]

In principe staat de ping er los van. Ik denk eerder dat je download niet genoeg verbindingen gebruikt.
Ik zou dus kijken naar een andere browser of download tool welke van de 2 je ook gebruikt.
Zo is Firefox bijvoorbeeld heel slecht in downloaden met meerdere verbindingen.
Het kan natuurlijk ook een instelling in je server settings zijn waardoor de verbindingen gelimiteerd worden.

Packet loss lijkt me ook niet het geval anders had je nooit die 400 Mbit gehaald met meerdere downloads.

[citruspers]

Dat kan. Je hebt namelijk Window Size, die bepaalt hoe veel data je in 1x "mag" verzenden voordat je een terugkoppeling verwacht. Een link met meer latency zal met dezelfde (kleine) window size minder data in dezelfde tijd kunnen versturen.

[PD2JK]

Als het TCP pakketjes zijn moet er continu een check gedaan worden of de pakketjes overgekomen zijn. Soort van zendbevestiging, wat met een hoge latency niet opschiet.

[Anoniem: 567735]

En er moet ook 'onderweg' genoeg bandbreedte zijn. Als die server in Zimbabwe staat, 2 uplinks heeft maar die uiteindelijk weer via hetzelfde draadje naar Johannesburg gan (en zo verder, of eentje naar Maputo en eentje naar Johannesburg, maar uiteindelijk via dezelfde lijn naar Europa), is het een ander verhaal dan naar bijvoorbeeld Singapore, waar veel meer verbindingen naar toe gaan, maar ook daar kan natuurlijk ook onderweg een flessenhals zitten. Die flessenhals kan overigens bij een andere provider compleet afwezig zijn vanwege andere peering policies, dus probeer ook meerdere providers.

[Glewellyn]

citruspers schreef op zaterdag 3 juli 2021 @ 16:48:
Dat kan. Je hebt namelijk Window Size, die bepaalt hoe veel data je in 1x "mag" verzenden voordat je een terugkoppeling verwacht. Een link met meer latency zal met dezelfde (kleine) window size minder data in dezelfde tijd kunnen versturen.

De spijker op z'n kop.

PD2JK schreef op zaterdag 3 juli 2021 @ 16:51:
Als het TCP pakketjes zijn moet er continu een check gedaan worden of de pakketjes overgekomen zijn. Soort van zendbevestiging, wat met een hoge latency niet opschiet.

Dat is op zich geen probleem, het bevestigen duurt alleen wat langer. Het probleem is zoals aangegeven de window size. De server wacht met meer pakketjes sturen tot er weer een bevestigd is.

Anoniem: 567735 schreef op zaterdag 3 juli 2021 @ 21:11:
En er moet ook 'onderweg' genoeg bandbreedte zijn. Als die server in Zimbabwe staat, 2 uplinks heeft maar die uiteindelijk weer via hetzelfde draadje naar Johannesburg gan (en zo verder, of eentje naar Maputo en eentje naar Johannesburg, maar uiteindelijk via dezelfde lijn naar Europa), is het een ander verhaal dan naar bijvoorbeeld Singapore, waar veel meer verbindingen naar toe gaan, maar ook daar kan natuurlijk ook onderweg een flessenhals zitten. Die flessenhals kan overigens bij een andere provider compleet afwezig zijn vanwege andere peering policies, dus probeer ook meerdere providers.

Dit kan in sommige gevallen inderdaad een probleem zijn. Maar als TS meer connecties opzet haalt hij wel de 200mbit. Het probleem zit hem dus niet in de throughput, ook niet halverwege.

[ Voor 32% gewijzigd door Glewellyn op 03-07-2021 21:20 ]

[laurens0619]

Ja afaik heeft delay wel impact op de effectieve bandbreedte. Komt idd door window size/packet loss/delay

Deze link legt het wel mooi uit

https://binat.eu/blog/doe...hieve-better-performance/

https://networkengineerin...nce-affect-download-speed

https://bradhedlund.com/2...-for-long-distance-links/

Of dit voorbeeld

Suppose you are sending a file from a server in Mumbai to a server in New Delhi. Both of these servers have 1 Gbps uplink and downlink speed. Now, one would think that the maximum speed while transferring data between these 2 servers will be 1 Gbps ( 128 MBps). But, this is not exactly what happens.

Lets take a standard sized TCP window of 64KB (524288 bits). Let the latency be 60 milliseconds (0.06s).

Now, the throughput obtained will be 524288/0.06 = 8.72 Mbps.

The speed might further decrease if the intermediate networks don't have the necessary bandwidth to support this speed

This speed can be increased by increasing the window size. But then it might lead to packet loss as the server memory buffer will overflow if more packets are coming in than going out.

[ Voor 72% gewijzigd door laurens0619 op 03-07-2021 21:38 ]

[Bl@ckbird]

Zoek even op BBR TCP en zet het aan op je server:
Wikipedia: TCP congestion control

[ Voor 10% gewijzigd door Bl@ckbird op 03-07-2021 22:16 ]

[Anoniem: 567735]

Glewellyn schreef op zaterdag 3 juli 2021 @ 21:17:
Dit kan in sommige gevallen inderdaad een probleem zijn. Maar als TS meer connecties opzet haalt hij wel de 200mbit. Het probleem zit hem dus niet in de throughput, ook niet halverwege.

Mea culpa - de leesbril lag naast de laptop in plaats van op mijn neus