Bandbreedte probleem

[Verwijderd]

Hoi,

Enkele maanden geleden merkte ik op dat bestanden downloaden van onze servers in het datacenter niet meer aan de lijnsnelheid verliep (60 megabit), zoals daarvoor wel het geval was. Ik gebruikte 2 locaties en 4 bestanden om te testen:

• 100mb.bin gehost door datacenter zelf
• 100mb.bin gehost op onze eigen servers
• 100mb.bin gehost door een hosting provider binnen hetzelfde datacenter
• 100mb.bin gehost door een andere hosting provider binnen hetzelfde datacenter

Resultaten:

Telenet - 60 Megabit

Het datacenter bestand haalt altijd 60 megabit.

Zowel de 100mbit bestanden gehost op onze servers, als 100mbit bestanden gehost door andere partijen zijn altijd bijzonder instabiel. De snelheid schommelt tussen 10 en 60 megabit.

Universiteitsnetwerk - 100 Megabit

Alle 100mb.bin bestanden halen de volledige snelheid.

Routes
De routes naar telenet en het universiteitsnetwerk toe zijn voor alle 100mb.bin bestanden consistent, ondanks dat ze zich in verschillende ip ranges bevinden. Ze horen wel degelijk bij hetzelfde AS.

Doordat op het universiteitsnetwerk de volledige snelheid wél bij alle bestanden kan gehaald worden, zou dit een beperking van de bandbreedte in het datacenter moeten uitsluiten, zou ik verwachten. Echter is het dan wel raar dat op de 60 megabit verbinding slechts 1 bestand altijd snel gaat. Dit doet namelijk vermoeden dat de beperking net wel in het datacenter ligt.

Spreekt dit elkaar niet tegen? Hoe zouden jullie dit gedrag verklaren?

[ItsValium]

Waarschijnlijk doet Telenet wel iets van QOS/bandwith throttling op de consumentenverbindingen. Ik merk hier net hetzelfde fenomeen, maar heb me er tot nu toe nog niet veel zorgen over gemaakt. Ik maak echter wel gebruik van een Fibernet 100 verbinding maar het fenomeen blijft bestaan.

Ik denk dat Telenet vooral op de iets drukkere nodes (centrum van grootsteden bijvoorbeeld) toch iets doet met beperkingen. Ik merk zelf dat tijdens de daluren (tussen middernacht en vijf uur 's morgens) het fenomeen nauwelijks optreed (dat is ook mijn backupslot voor een aantal servers).

[Verwijderd]

QOS en Bandwith throttling zijn uiteraard een mogelijkheid. De routes voor de 100mb.bin bestanden zijn echter volledig hetzelfde. Dus als minstens 1 bestand wel de volledige snelheid haalt, zou er naar het datacenter geen traffic shaping / QOS /.. actief mogen zijn op dat moment vermoed ik.

[Uberprutser]

Verwijderd schreef op zondag 29 januari 2012 @ 17:57:
Echter is het dan wel raar dat op de 60 megabit verbinding slechts 1 bestand altijd snel gaat.
Hoe zouden jullie dit gedrag verklaren?

Je hebt het over een consumentenlijn met een overboeking van misschien wel 1:100; die 60Mbit is niet gegarandeerd.

De universiteit kan (vrijwel) 1:1 aanbieden waardoor je die snelheid nagenoeg altijd zal halen.

[RocketKoen]

Hoe vaak heb je de test herhaald?
het zou namelijk gewoon puur toeval kunnen zijn dat net netwerk van telenet minder belast was toen je het bestand van het datacenter downloadde.

En gebruiken al je downloads hetzelfde protocol en poort?
Ik kan me namelijk voorstellen dat telenet poort 80 (http) verkeer voorrang geeft op poort 21 (ftp).
Ook het gebruik van wel of geen SSL kan een verschil maken.

[Verwijderd]

Alvast bedankt voor de antwoorden

RocketKoen schreef op maandag 30 januari 2012 @ 09:12:
Hoe vaak heb je de test herhaald?

Afgelopen week elke dag een paar keer.

RocketKoen schreef op maandag 30 januari 2012 @ 09:12:
het zou namelijk gewoon puur toeval kunnen zijn dat net netwerk van telenet minder belast was toen je het bestand van het datacenter downloadde.

Klopt, daarom test ik ze steeds meerdere malen achter elkaar.

RocketKoen schreef op maandag 30 januari 2012 @ 09:12:
En gebruiken al je downloads hetzelfde protocol en poort?
Ik kan me namelijk voorstellen dat telenet poort 80 (http) verkeer voorrang geeft op poort 21 (ftp).

Ik heb bovenaan de linkjes mee geplaatst, dit zijn allemaal poort 80 addressen zonder ssl of dergelijks.

Ballebek schreef op maandag 30 januari 2012 @ 09:01:
[...]

Je hebt het over een consumentenlijn met een overboeking van misschien wel 1:100; die 60Mbit is niet gegarandeerd.

De universiteit kan (vrijwel) 1:1 aanbieden waardoor je die snelheid nagenoeg altijd zal halen.

Natuurlijk is de telenet verbinding overboekt. Maar als ik echt élke test op het eerste bestand de volledige snelheid haal, en de rest maar 10-30 megabit, dan ligt het toch daar niet aan zou ik denken?

[AndriesLouw]

Dit kan van alles zijn, hoe hangen je servers bij Technotop aan de switch? 100Mbit/s, of netjes het volledige pad Gbit/s bekabeld? Kan me voorstellen dat er pakketjes droppen onderweg, en dat je dus meer capaciteit nodig hebt om alsnog een 100Mbit/s stabiel te halen. Daarnaast kan Technotop anti-DDoS apparatuur voor je servers hebben gezet, en hierbij Telenet verbindingen hebben beperkt.

Mijn advies: Neem even contact op met Technotop zelf, ze weten vaak wel af van netwerkproblemen, of kunnen je vertellen wie je wel moet hebben. Daarnaast zijn zij de enigen die kunnen onderzoeken waar een bottleneck zit qua netwerktopologie.

Edit: En als je de boel ondergebracht hebt bij Versio kun je dat ook gewoon zeggen, en moet je bij hun zijn. Klop dus aan bij je provider. Mocht je zelf het netwerk beheren dan kunnen wij je pas helpen, anders zijn de analyses hier puur giswerk.

[ Voor 16% gewijzigd door AndriesLouw op 31-01-2012 17:23 ]

[MAX3400]

Net even voor je getest maar ik krijg echt hele andere waarden op het eerste bestand; in tegenstelling tot de 60Mbit waar je het over hebt, haal ik 60MB/s:

code:

root@:/# wget http://technotop.nl/100mb.bin
--2012-01-31 17:20:32--  http://technotop.nl/100mb.bin
Resolving technotop.nl... 91.196.170.72
Connecting to technotop.nl|91.196.170.72|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `100mb.bin.1'

100%[==================================================================================>] 104,857,600 56.3M/s   in 1.8s

2012-01-31 17:20:33 (56.3 MB/s) - `100mb.bin.1' saved [104857600/104857600]

root@:/# wget http://technotop.nl/100mb.bin
--2012-01-31 17:20:34--  http://technotop.nl/100mb.bin
Resolving technotop.nl... 91.196.170.72
Connecting to technotop.nl|91.196.170.72|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `100mb.bin.2'

100%[==================================================================================>] 104,857,600 60.3M/s   in 1.7s

2012-01-31 17:20:36 (60.3 MB/s) - `100mb.bin.2' saved [104857600/104857600]

root@:/# wget http://technotop.nl/100mb.bin
--2012-01-31 17:20:37--  http://technotop.nl/100mb.bin
Resolving technotop.nl... 91.196.170.72
Connecting to technotop.nl|91.196.170.72|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `100mb.bin.3'

100%[==================================================================================>] 104,857,600 63.5M/s   in 1.6s

2012-01-31 17:20:38 (63.5 MB/s) - `100mb.bin.3' saved [104857600/104857600]

root:/# wget http://technotop.nl/100mb.bin
--2012-01-31 17:20:39--  http://technotop.nl/100mb.bin
Resolving technotop.nl... 91.196.170.72
Connecting to technotop.nl|91.196.170.72|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `100mb.bin.4'

100%[==================================================================================>] 104,857,600 54.1M/s   in 1.8s

2012-01-31 17:20:41 (54.1 MB/s) - `100mb.bin.4' saved [104857600/104857600]

[PerfectPC]

Heb het net even getest en ik merk inderdaad een gelijkaardige anomaliteit:
Met een Telenet Business 70 abo:
- 1 à 2 MB/s naar 91.196.171.203
- 6 à 7 MB/s naar 91.196.170.72
Vanaf Hetzner 100Mbps:
- 8 à 10 MB/s naar 91.196.171.203
- 8 à 10 MB/s naar 91.196.170.72

Wat me wel opvalt is dat de route niet overal gelijk is... (zelfde volgorde als de tests)

code:

[pieter@CactiEZ tmp]$ traceroute 91.196.171.203
traceroute to 91.196.171.203 (91.196.171.203), 30 hops max, 40 byte packets
 1  intern.router.rumst.verbert.be (192.168.59.1)  3.657 ms  3.755 ms  3.923 ms
 2  d5152c001.static.telenet.be (81.82.192.1)  9.974 ms  10.673 ms  11.804 ms
 3  dd5e0c5e1.access.telenet.be (213.224.197.225)  12.007 ms  12.499 ms  13.388 ms
 4  dd5e0f86a.access.telenet.be (213.224.248.106)  9.969 ms  10.114 ms  13.359 ms
 5  tengigabitethernet3-3.ar1.ndl1.gblx.net (64.210.31.249)  20.229 ms 
    te3-2.ar1.nld1.ant1.gblx.net (64.215.184.29)  20.409 ms  20.603 ms
 6  atrato-ip-networks-as5580.tengigabitethernet1-3.ar4.ams2.gblx.net (207.138.128.42)  35.512 ms  31.449 ms  32.773 ms
 7  tge1-1.ams02-1.eu.as5580.net (78.152.34.10)  21.038 ms  19.261 ms  28.659 ms
 8  rijndata-gw.r1.ams2.nl.as5580.net (78.152.63.194)  20.115 ms  20.604 ms  22.543 ms

[pieter@CactiEZ tmp]$ traceroute 91.196.170.72
traceroute to 91.196.170.72 (91.196.170.72), 30 hops max, 40 byte packets
 1  intern.router.rumst.verbert.be (192.168.59.1)  3.712 ms  3.840 ms  4.010 ms
 2  d5152c001.static.telenet.be (81.82.192.1)  8.511 ms  8.726 ms  8.803 ms
 3  dd5e0c5e1.access.telenet.be (213.224.197.225)  9.024 ms  12.635 ms  13.539 ms
 4  dd5e0f86a.access.telenet.be (213.224.248.106)  62.975 ms  63.151 ms  63.125 ms
 5  te3-2.ar1.nld1.ant1.gblx.net (64.215.184.29)  19.464 ms  19.999 ms  20.494 ms
 6  atrato-ip-networks-as5580.tengigabitethernet1-3.ar4.ams2.gblx.net (207.138.128.42)  23.611 ms  33.459 ms  33.758 ms
 7  tge1-1.ams02-1.eu.as5580.net (78.152.34.10)  35.266 ms  25.278 ms  23.508 ms
 8  rijndata-gw.r1.ams2.nl.as5580.net (78.152.63.194)  24.886 ms  25.390 ms  28.386 ms

[pieter@odin tmp]$ traceroute 91.196.171.203
traceroute to 91.196.171.203 (91.196.171.203), 30 hops max, 40 byte packets
 1  pfsense.verbert.be (78.46.134.193)  0.629 ms  0.613 ms  0.593 ms
 2  static.241.175.46.78.clients.your-server.de (78.46.175.241)  1.952 ms  1.949 ms  1.942 ms
 3  hos-tr3.juniper2.rz6.hetzner.de (213.239.252.1)  0.947 ms 
    hos-tr2.juniper1.rz6.hetzner.de (213.239.229.129)  0.953 ms 
    hos-tr4.juniper2.rz6.hetzner.de (213.239.252.129)  0.947 ms
 4  hos-bb1.juniper1.ffm.hetzner.de (213.239.240.224)  7.113 ms  7.097 ms  7.097 ms
 5  tge4-4.fra02-1.eu.as5580.net (80.81.194.66)  18.437 ms  5.423 ms  4.983 ms
 6  tge4-1.ams01-1.eu.as5580.net (78.152.34.29)  19.343 ms  12.444 ms  13.288 ms
 7  tge1-2.ams02-1.eu.as5580.net (78.152.34.14)  12.242 ms  11.749 ms  12.174 ms
 8  rijndata-gw.r1.ams2.nl.as5580.net (78.152.63.194)  12.168 ms  12.852 ms  12.148 ms

[pieter@odin tmp]$ traceroute 91.196.170.72
traceroute to 91.196.170.72 (91.196.170.72), 30 hops max, 40 byte packets
 1  pfsense.verbert.be (78.46.134.193)  0.674 ms  0.654 ms  0.645 ms
 2  static.241.175.46.78.clients.your-server.de (78.46.175.241)  1.735 ms  1.726 ms  1.703 ms
 3  hos-tr3.juniper2.rz6.hetzner.de (213.239.252.1)  0.991 ms  0.993 ms 
    hos-tr2.juniper1.rz6.hetzner.de (213.239.229.129)  0.985 ms
 4  hos-bb1.juniper1.ffm.hetzner.de (213.239.240.224)  4.352 ms  4.324 ms  4.333 ms
 5  tge1-3.fra01-1.eu.as5580.net (80.81.195.66)  5.454 ms  5.457 ms  5.720 ms
 6  tge2-1.dus01-1.eu.as5580.net (78.152.34.41)  14.556 ms  7.697 ms  15.962 ms
 7  tge1-3.ams02-1.eu.as5580.net (78.152.34.37)  21.147 ms 
    rijndata-gw.r1.ams2.nl.as5580.net (78.152.63.194)  13.203 ms 
    tge1-3.ams02-1.eu.as5580.net (78.152.34.37)  20.621 ms

[Koffie]

Move PNS > NT