Weinig bandbreedte (500KB/s per thread)

[christopheb]

Hoi,

Ik zou graag jullie raad vragen over volgende situatie: wij hebben servers in het datacenter van alphen aan de rijn (rijndata). Sinds december 2011 halen we maar 500KB/s per verbinding (dus bijvoorbeeld een 100mb.bin via de browser). De provider (AS5580 - Atrato) heeft ook een speedtest bestand ter beschikking gesteld, die gaat ook traag, dus het probleem ligt niet bij het datacenter.

Concreet
Telenet (120mbps)
Universiteit (100mbps)
Rijndata (1Gbps)

Een verbinding van rijndata naar telenet haalt maar 500KB/s. Met meerdere verbindingen kan wel de volledige snelheid behaald worden.
Verbinding naar de universiteit loopt perfect, maar gaat via een andere route.

Traceroutes:

Home to DC
HOST: ubuntu-server-1110          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- pfsense-vm.pfsense.esx.ho  0.0%    20    0.4   0.5   0.3   1.2   0.2
  2.|-- 94-226-32-1.access.telene  0.0%    20    5.7   8.2   5.4  31.0   6.0
  3.|-- dD5E0C5C1.access.telenet. 30.0%    20    7.0   7.3   6.8   8.8   0.5
  4.|-- dD5E0FD11.access.telenet.  0.0%    20    8.2  10.8   7.9  43.0   7.9
  5.|-- ae7.bru20.ip4.tinet.net    0.0%    20    8.0  14.4   7.5  75.1  16.9
  6.|-- xe-5-2-0.ams20.ip4.tinet.  0.0%    20   12.4  15.5  11.7  48.6   9.3
  7.|-- atrato-gw.ip4.tinet.net    0.0%    20   16.3  19.6  13.7  32.3   5.2
  8.|-- tge1-1.ams05-1.nl.as5580.  0.0%    20   13.4  17.5  13.0  28.6   5.0
  9.|-- noc.as5580.net             0.0%    20   14.3  14.9  14.3  15.6   0.4
  
DC to Home
HOST: ubuntuserver                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 10.1.0.1                      0.0%    20    0.4   0.5   0.3   1.3   0.3
  2. r1.ams2.nl.as5580.net         0.0%    20   26.5  19.9   0.9  42.3  17.1
  3. tge2-1.ams09-1.nl.as5580.net  0.0%    20    9.1   7.2   1.1  20.6   7.2
  4. tge4-3.ams01-1.nl.as5580.net  0.0%    20    1.3   3.7   1.2  12.1   3.5
  5. asd2-rou-1043.NL.eurorings.n  0.0%    20    4.5   4.7   3.2  19.2   4.0
  6. asd2-rou-1022.NL.eurorings.n  5.0%    20    8.2   9.5   6.9  33.2   5.9
  7. zvtm-s1-rou-1041.BE.euroring  0.0%    20    8.2  10.2   6.9  57.2  11.1
  8. zvtm-s1-rou-1042.BE.euroring  0.0%    20    8.0  15.6   8.0  82.9  22.9
  9. telenet2.bnix.net            50.0%    20    5.6   5.6   5.5   5.8   0.1
 10. dD5E0FD12.access.telenet.be  35.0%    20    5.9   6.8   5.9   8.6   1.0
 11. dD5E0FD12.access.telenet.be  30.0%    20    9.0   9.7   8.1  15.2   1.7
 12. *****.access.telenet  0.0%    20    9.6  14.1   9.4  44.5   7.6

Telenet doet aan icmp throttling, verder lijkt mij niets mis met de traces.

Metingen van de TCP verbinding geven aan dat er veel retransmits, duplicates etc zijn:

Interval: 30.000 secs
Column #0: COUNT(tcp.analysis.retransmission) tcp.analysis.retransmission
Column #1: COUNT(tcp.analysis.duplicate_ack)tcp.analysis.duplicate_ack
Column #2: COUNT(tcp.analysis.lost_segment) tcp.analysis.lost_segment
Column #3: COUNT(tcp.analysis.fast_retransmission) tcp.analysis.fast_retransmission
                |   Column #0    |   Column #1    |   Column #2    |   Column #3
Time            |          COUNT |          COUNT |          COUNT |          COUNT
000.000-030.000               116              548              108               92
030.000-060.000               114              812              104               89
060.000-090.000               118              665               96               84
090.000-120.000               120              621              105               92
120.000-150.000               117              760              102               91
150.000-180.000               106              734               93               81
180.000-210.000               100              628               88               79
210.000-240.000                25              125               22               19

Bij andere 100mb.bin testbestanden staan deze tellers zo goed als op 0, en wordt wél de volledige snelheid gehaald. Het probleem ligt dus bij een instabiele tcp verbinding (packet loss?).

Hoe zouden jullie dit aanpakken? Ik heb beide partijen (Telenet en Atrato) reeds gemaild, en ze zeggen allebei dat het probleem niet bij hun ligt.

[Exsilia]

De waarden die je in je laatste tabelletje laat zien lijken me inderdaad niet in orde. Daar moet ik wel bijzeggen dat je neit laat zien wat het totaal aantal pakketten is geweest, dus ik kan er geen percentage uit afleiden. Dat is natuurlijk wel van belang om aan te geven of het aantal retransmissions, e.d. relatief hoog is of "normaal".

Echter, je geeft zelf al aan dat als je vanaf huis een andere 100mb.bin download je het probleem niet hebt. In andere woorden doet het zich alleen voor bij jou server bij rijndata? Als je met meerdere threads wel een hogere snelheid haalt, dan moet het eigenlijk haast wel ergens een speedlimit zijn. Bij alle andere problemen zoals duplex issues, retransmissions en weet ik het wordt geen onderscheid gemaakt in het aantal threads.

Misschien kun je hier een linkje plaatsen naar een 100mb.bin op de betreffende server? dan kunnen wij ook een testje doen. Maar op basis van jou informatie zou ik toch nog eens je provider vragen er eens naar te kijken.

[christopheb]

De vertraging is enkel bij onze servers bij rijndata, klopt.

Het totaal aantal pakketten is ongeveer 106.000. Het aantal lost segments komt dan op 1%, duplicate ack's op 8%, retransmissions op 1% en fast retransmissions ook op 1%.

Wat me zorgen baart zijn die duplicate ack's. Bij andere 100mb.bin testbestanden (die wel snel gaan), zijn er praktisch geen lost segments, duplicate acks,... hooguit één of twee.

Zou het toevallig kunnen dat KPN (Eurorings) ergens traffic shaping toepast onderweg?

[systemdeveloper]

Die duplicate ack's krijg je over het algemeen (even een faulty switch buiten beschouwing gelaten) als je ergens van een snelle pijplijn naar een minder snelle overgaat of dat ergens je traffic over 2 verschillende routes binnenkomt. Het is namelijk mogelijk dat bepaalde tcp segmenten niet in de juiste volgorde binnenkomen. Een duplicate ack wordt nmelijk verstuurd in geval van o.a. congestion op het netwerk of om de andere kant van de verbinding te laten weten welk tcp packet eigen verwacht werd. Daarnaast 'weet' tcp niet de oorzaak van een duplicate ack en neemt aan dat het a) een reorder van de segmenten moeten zijn (ingeval van enkele dup. acks) of een lost packet (bij meerdere dup. acks).
Wat dat betreft kloppen de getallen dus wel: 1% fast retransmissions als gevolg van 2-3% dup. acks (out of order segments), die 1% lost komt overeen met 4-5% dup acks. (lost segment) en 1% vanwege de 1% retransmissions.

Either way, voor 1% lost segments en 1% fast retransmissions is 8% duplicate acks 'normaal'. Wat de exacte oorzaak is zou ik zo ook niet kunnen zeggen maar het lijkt wel ergens een hardware issue te zijn. Misschien een bond ergens waarbij 1 nic dood is.

[Exsilia]

Een bond of ander hardware issue kan het volgens mij niet zien. Dat verklaart namelijk niet dat een thread op een specifieke snelheid blijft hangen. Immers, een bond, etherchannel fo wat dan ook heeft geen besef van IP, laat staan van TCP.

Al dat het probleem is kan het dus niet zo zijn dat meerdere threads ineens wel een hogere gezamelijke bandbreedte halen.

[Exsilia]

Maar misschien kan de TS een linkje naar een 100mb.bin op de betreffende server plaatsen? Dan kunnen wij het ook testen om te kijken of het probleem zich dan ook voor doet. Zoja, dan heb je in ieder geval richting Rijndata al wat meer overwicht.

[systemdeveloper]

Een bond of ander hardware issue kan het volgens mij niet zien. Dat verklaart namelijk niet dat een thread op een specifieke snelheid blijft hangen. Immers, een bond, etherchannel fo wat dan ook heeft geen besef van IP, laat staan van TCP.

Al dat het probleem is kan het dus niet zo zijn dat meerdere threads ineens wel een hogere gezamelijke bandbreedte halen.

Maak maar eens ergens een bond met een inferieure kabel of een ander pruttelmerk nic. De hw hoeft dan niet kapot te zijn maar je gaat geen topspeed halen omdat je verbinding met die retransmissions te maken blijft hebben. Maar het kan ook net zo goed een firewall ergens zijn die trafficshaping per connectie doet, beetje zoals dat vroegah 'omzeilt' werd met downloadmanagers.
Fast retransmissions heb je normaal alleen als je packets out of order binnenkomen. Nou ja, zonder kijkje in de keuken blijft het een beetje gissen (althans voor mij)

[Wido]

Ik heb dit probleem ooit ook gehad. Wij konden achter onze ZeelandNet verbinding per TCP sessie met maximaal 500KB/sec downloaden uit het ReasonNet netwerk.

Dit is toen door gespeeld aan ReasonNet en zij hebben het met ZeelandNet samen opgelost, maar ook wij bleven precies op 500KB/sec per TCP sessie hangen.

[christopheb]

Bedankt voor de reacties en inzichten. Ik heb atrato gemaild maar tot op heden nog geen antwoord. Wel vermoed ik dat het probleem zich voordoet bij KPN. Toen er een tijd geleden een netwerkprobleem was en KPN niet gebruikt werd om te routen, ging alles vlekkeloos. Maar ik wacht even hun reactie af.

Als linkje kunnen jullie deze gebruiken: 100mb.bin.

[t.bloo]

Ik trek op al mijn verbindingen in drie datacentra, adsl en 3g de lijnen dicht met deze download.

[cyberbootje]

Hier gaat het ook helemaal goed, upc en meerdere DC's.
Zelfs net testje vanuit US gedaan, trekt hem helemaal dicht dus bij Atrato kan het niet liggen lijkt me.

[Spyder01]

Gewoon even via m`n thuislijntje van Ziggo gedownload, tot 50% zat het rond de 6Mb/s, daarna zakte het in tot ongeveer 2,5.

[Exsilia]

Hier ook hetzelfde inderdaad. Ik trek mijn 100 Mbit helemaal dicht.

Maak maar eens ergens een bond met een inferieure kabel of een ander pruttelmerk nic. De hw hoeft dan niet kapot te zijn maar je gaat geen topspeed halen omdat je verbinding met die retransmissions te maken blijft hebben.

Maar dat is dus het gekke, TS haalt wel "topspeeds" met meerdere threads.

[Exsilia]

Maargoed, we kunnen denk ik inderdaad wel de conclusie trekken dat het probleem dus in ieder geval niet direct bij Atrato ligt. Het ligt of aan je netwerk/infra thuis of iets tussen jou thuis en je server. Je zou eigenlijk iemand met Telenet moeten vragen of die wel goede snelheden haalt.

[christopheb]

Ik heb inderdaad ook aan vrienden met telenet gevraagd om te testen, deze hebben hetzelfde probleem.