Bakgrund

Det började med att jag blev irriterad över att min nerladdningshastighet minskade så drastiskt samtidigt som en uppladdning skedde. Efter en hel del forskande kom jag fram till att ACK fastnade i sändkön flera hundra millisekunder, därför stoppar servern att skicka data tills den får ett ACK om att skicka mer. När jag nästan ett år senare fick installerat en Linux-gateway så kunde jag börja experimentera. Det var inte så mycket skrivet om traficshaping då, men jag hittade en site: www.docum.org som tog upp det väsentliga jag behövde veta. Stef Coene bakom www.docum.org ska ha en massa eloge för vad jag presenterar här.

Beskrivning

Matematiskt borde problemet te sig så här:
Med en standard Windows2000/XP burk tillåter TCP/IP-stacken en fönsterstorlek på max 65536 bytes.
Antal maxstora paket på en 2mbit koppling är ca 250000bytes/s / 1500bytes = 166st
1000ms (en sekund) / 166st paket = 6ms. Ett 1500 bytes stort TCP-paket upptar ca 6ms i tid på en 2mbit koppling.
Antal paket på 65536 bytes fönster, 65536 / 1500 = 43st
43 x 6 = 258ms. Minus fördröjning mot server (i mitt testfall ca 30ms)
258 - 30 = 228.

Det får alltså dröja max ca 228ms innan vi svarar med ett ACK för att inte nerladdningen ska begränsas.

Testerna

Nedan kommer 4 tester. Min uppkoppling är på:
downstream: 2mbit
upstream: ca 360kbit

Testerna består utav att:
ladda upp fil
ladda ner och ladda up fil samtidigt
För att mäta använder jag 3 program:
bang som är en bandbreddsmätare
ping som mäter fördröjning
bwbar som mäter bandbredd över tid och producerar grafik och data (mest för webpresentation)

Utan shape (TX)

$ bang eth0 -c 10 -n
RX=1026, TX=48448 seq=1 time=1
RX=900, TX=45420 seq=2 time=1
RX=1206, TX=27252 seq=3 time=1
RX=720, TX=45420 seq=4 time=1
RX=960, TX=49962 seq=5 time=1
RX=840, TX=45420 seq=6 time=1
RX=960, TX=49962 seq=7 time=1
RX=900, TX=48448 seq=8 time=1
RX=918, TX=40878 seq=9 time=1
RX=942, TX=31794 seq=10 time=1

--- eth0 bandwitdh statistics ---
RX bandwidth min/avg/max = 720/937/1206
TX bandwidth min/avg/max = 27252/43300/49962

$ ping pop -c 10 -q (pop = point of presence)
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/mdev = 103.083/204.169/353.484/76.240 ms

Incoming Current bandwidth utilization 7.33 kbit/s  

Outgoing Current bandwidth utilization 354.34 kbit/s

Utan någon form av traficshaping flukturerar latency mycket, men hastigheten påverkas inte mycket. Kör man interaktivt (telnet, ssh mm.) känns det tydligt att latency flukturerar.

Utan shape (RX, TX)

$ bang eth0 -c 10 -n
RX=186814, TX=43930 seq=1 time=1
RX=93800, TX=43932 seq=2 time=1
RX=86786, TX=45862 seq=3 time=1
RX=61448, TX=30760 seq=4 time=1
RX=219848, TX=40116 seq=5 time=1
RX=169638, TX=49658 seq=6 time=1
RX=128386, TX=50314 seq=7 time=1
RX=134148, TX=41362 seq=8 time=1
RX=118110, TX=46370 seq=9 time=1
RX=122652, TX=45574 seq=10 time=1

--- eth0 bandwitdh statistics ---
RX bandwidth min/avg/max = 61448/132163/219848
TX bandwidth min/avg/max = 30760/43788/50314

$ ping pop -c 10 -q
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/mdev = 192.584/241.725/300.969/37.006 ms

Incoming Current bandwidth utilization 1017.33 kbit/s  

Outgoing Current bandwidth utilization 335.86 kbit/s

Här är hela orsaken till detta dokument. Mottagning är en enda stor bergodalbana och den effektiva mottagningshastigheten är i princip halverad. Även uthastigheten hoppar mycket. Fördröjningen är som väntat sämst i denna test med ett genomsnitt på 241,7ms.

Med shape (TX)

$ bang eth0 -c 10 -n
RX=1320, TX=42392 seq=1 time=1
RX=1320, TX=45566 seq=2 time=1
RX=1320, TX=42538 seq=3 time=1
RX=1446, TX=44052 seq=4 time=1
RX=1434, TX=44052 seq=5 time=1
RX=1320, TX=44052 seq=6 time=1
RX=1320, TX=45566 seq=7 time=1
RX=1320, TX=42538 seq=8 time=1
RX=1386, TX=44052 seq=9 time=1
RX=1320, TX=45566 seq=10 time=1

--- eth0 bandwitdh statistics ---
RX bandwidth min/avg/max = 1320/1351/1446
TX bandwidth min/avg/max = 42392/44037/45566
-----------------

$ ping pop -c 10 -q
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/mdev = 11.184/28.735/43.639/11.320 ms
-----------------

Incoming Current bandwidth utilization 7.33 kbit/s  

Outgoing Current bandwidth utilization 350.95 kbit/s

Om man jämför med utan shaping så är round-trip överlägset bättre:
med shape round-trip min/avg/max/mdev = 11.184/28.735/43.639/11.320 ms
utan shape round-trip min/avg/max/mdev = 103.083/204.169/353.484/76.240 ms

Jag testade även att spela Quake3 över internet samtidigt. Normalt så blir det ju helt ospelbart med samtidig upload, men nu var det helt spelbart. Pingen fluktade mot den aktuella spelservern från ca 22ms till 50ms och netgraphen var stabil med någon pixels bergodalbana.

Med shape (RX, TX)

$ bang eth0 -c 10 -n
RX=253268, TX=43658 seq=1 time=1
RX=254716, TX=45318 seq=2 time=1
RX=254352, TX=43870 seq=3 time=1
RX=253202, TX=43804 seq=4 time=1
RX=254220, TX=45318 seq=5 time=1
RX=254848, TX=42356 seq=6 time=1
RX=254220, TX=43804 seq=7 time=1
RX=253268, TX=45318 seq=8 time=1
RX=254286, TX=43870 seq=9 time=1
RX=254716, TX=43804 seq=10 time=1

--- eth0 bandwitdh statistics ---
RX bandwidth min/avg/max = 253202/254110/254848
TX bandwidth min/avg/max = 42356/44112/45318

$ ping pop -c 10 -q
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/mdev = 215.174/239.920/256.376/13.128 ms

Incoming Current bandwidth utilization 2002.66 kbit/s

Outgoing Current bandwidth utilization 340.59 kbit/s

Här kommer det intressanta. Som du ser så "maxar" bägge linorna samtidigt. Att pingen är såpass hög beror på att det inte är någon trafic-shaping i andra ändan.
Detta går att lösa, jag kan flytta inkommande kön från ISP'n till mig genom att begränsa inkommande hastighet på min site en aning. Men det vill jag inte, eftersom tillfällena när jag kör interaktiv trafik samtidigt som jag downloadar till max är för få.

Fortsätt