Wij hebben bij Multikabel een 4 Mbit (full-duplex) glasvezel internet verbinding.
Nu is mij opgevallen dat wanneer ik een groot bestand download ik die netjes met ruim 450 Kbytes/s binnenhaal, maar wanneer ik tijdens die download een groot bestand upload, dan haal ik nog geen eens 180 Kbytes/s
Wanneer ik dan de download afbreek, schiet de upload naar 450 Kbytes/s
Dit probleem is onderzocht door Multikabel, waarbij hun test van de lijn uitwijst dat er netjes een 4 Mbit full-duplex verbinding is.
Ik heb laten zien hoe de download altijd de upload wegdrukt, ook vanaf verschillende pc's.
Volgens hun klopt dit niet.
Nou krijg ik een mailtje van Multikabel met dit verhaal, wat eigenlijk zegt dat je van een 4 Mbit full-duplex verbinding eigenlijk maar een 2 Mbit snelheid mag verwachten.
Nu is mij opgevallen dat wanneer ik een groot bestand download ik die netjes met ruim 450 Kbytes/s binnenhaal, maar wanneer ik tijdens die download een groot bestand upload, dan haal ik nog geen eens 180 Kbytes/s
Wanneer ik dan de download afbreek, schiet de upload naar 450 Kbytes/s
Dit probleem is onderzocht door Multikabel, waarbij hun test van de lijn uitwijst dat er netjes een 4 Mbit full-duplex verbinding is.
Ik heb laten zien hoe de download altijd de upload wegdrukt, ook vanaf verschillende pc's.
Volgens hun klopt dit niet.
Nou krijg ik een mailtje van Multikabel met dit verhaal, wat eigenlijk zegt dat je van een 4 Mbit full-duplex verbinding eigenlijk maar een 2 Mbit snelheid mag verwachten.
Dit is toch gewoon onzin? Voor ongeveer 900 euro excl. btw per maand mag je toch verwachten dat een 4 Mbit verbinding gewoon 4 Mbit is??Eerst een korte uiteenzetting over het TCP connection oriented protocol
Quote: “TCP’s sliding congestion window. It allows the sender to send a certain amount of data without having received an ACK from the receiver yet. This mechanism is dynamic.”
Bandwith delay product (BDP) maximum TCP windows size possible. Most optimal TCP window size
RTT = 10msec
Bw = 4Mb
4.000.000 * 1/8 * 0,01 = 5000 bytes
D.w.z. Alleen als de TCP window size van de applicatie 5000 bytes is dan haal je een throughput op de lijn van 4Mb/s. Bij een grotere window size zal het TCP congestion avoidance algorithm ingrijpen en de window size weer kleiner maken, bij een kleinere window size zal je geen 4Mb thoughput halen. Dit mechanisme is dynamisch en dat maakt het gedrag in de praktijk daardoor lastig te voorspellen.
Echt duidelijk voorspellen van de te halen bandbreedte in de praktijk is met TCP sessies is bijna onmogelijk omdat er te veel factoren zijn die een rol spelen, de round trip tijd is bijvoorbeeld ook afhankelijk van de CPU load van de machines vanaf waar de sessies lopen, verder is er nogal een diversiteit in de te halen maximum TCP window size per OS en of TCP stack implementatie van de machines waarop gemeten wordt.
Metingen wijzen uit dat als er twee sessies tegelijk gestart worden de maximale bandbreedte per sessie de helft van de bandbreedte is. Dit wordt door het TCP congestion avoidance algorithm bepaald. zie ook http://www.opalsoft.net/qos/Flows.htm
Klaarblijkelijk is er gemeten dat een download FTP van 4Mb gehaald kan worden, als er dan tegelijkertijd een upload wordt gestart is deze maximaal 2Mb, twee downloads tegelijk halen elk 2Mb.
De oplevering is uitgevoerd met een EXFO analyzer, deze start twee UDP flows (A-> B, B -> A) twee richtingen tegelijk, UDP heeft als voordeel/nadeel dat het een connection-less protocol is en geen congestion avoidance algorithm machanisme heeft. Met deze test is bewezen dat de verbinding wel degelijk een full duplex 4Mb verbinding is.
Misschien is het mogelijk dat er een test gedaan kan worden i.s.m. waarbij een UDP flow vanaf twee locaties tegelijk wordt gestart. Zie ook url http://dast.nlanr.net/Projects/Iperf/, hiermee is het mogelijk UDP sessies tussen een client en server te starten. Mogelijk ziet u kans hiermee te experimenteren.