Transatlantische verbinding, snelheden laag vanuit Nederland

[A.Kebab]

Hoi allen,

Ik schrijf dit op het moment vanuit Los Angeles. Ik ga hier binnenkort voor een onbepaalde tijd wonen en een van de dingen die mij opviel is dat de verbinding naar europa nogal traag is.

De verbindingen naar de EU halen max 2-300 KB/s en hebben vaak flinke pieken en dalen. Streaming video op Tweakers en dumpert.nl gaan bijvoorbeeld ook als dikke stront door een trechter. Ik kan wel gewoon 2,5 MB/s halen op nationale websites.

Is dit een inherente eigenschap van transatlantische verbindingen of is het gewoon mogelijk een snelle en stabiele verbinding te krijgen met de andere kant van de plas? Zoja: waar zou ik dan op moeten letten? Ik kan op sites van de grote providers hier helaas niks vinden over transatlantische verbindingen.

Alvast dank!

[Iekozz]

Welke ISP heb je daar? En welke snelheid? Zijn er ook websites die het wel goed doen? Alle transatlantische kabels zijn allemaal van glasvezel, dus dat is het probleem sowieso niet. Zou het toch meer zoeken in je eigen apparatuur/netwerk.

[CyBeR]

Nee, dat is niet inherent aan de afstand. Althans, niet direct. Van invloed is wel de latency tussen de EU en de VS. Dat maakt dat heel veel kleine requests naar het web wel langer duren (immers, het duurt langer voor jouw request hier aan komt en vice versa duurt 't langer voor ons antwoord bij je terug is en als je dat vaak herhaalt gaat dat optellen) maar dat is latency, niet bandbreedte.

De bandbreedte is op zich niet afhankelijk van de latency maar wordt er, afhankelijk van je settings, wel door beinvloed. De settings die dit beinvloeden zijn je TCP send en receive windows. Zet die eens wat groter dan de defaults.

Zie ook Wikipedia: Bandwidth-delay product.

[ Voor 11% gewijzigd door CyBeR op 12-02-2013 02:10 ]

[painkill]

Doet mij trouwens denken aan een verhaal over iemand welke maar 300KM kon e-mailen. Als de ontvanger verder dan die afstand zat dan kwamen zijn e-mails niet aan. Uiteindelijk ook een instelling, maar kom er maar eens achter

[A.Kebab]

Het probleem doet zich voor op verschillende verbindingen. Een zakelijke verbinding was het snelst en daar kon ik 600KB/s van de beschikbare 1MB/s halen. Heb daarnaast nog 3/4 andere verbindingen getest die allemaal rond de 300 KB/s bleven steken waarbij sommige toch wel 2.5MB/s konden halen. Volgens mij waren de meeste verbindingen van Time Warner en eentje van AT&T.

Het is in ieder geval goed om te horen dat de afstand niet de beperkende factor is. M'n huidige aansluiting (ik wissel zo nu en dan van tijdelijke woning) heeft een shitty router met bijzonder weinig instellingen dus kan op het moment helaas niet fiddlen met de TCP windows. Wel goed om te weten dat dit eventueel effect kan hebben voor wanneer ik weer een geavanceerde router beschikbaar heb!

PS: Ik gebruik megabytes en kilobytes om de snelheden te beschrijven, voor het geval hier verwarring over is

[ Voor 12% gewijzigd door A.Kebab op 12-02-2013 03:36 ]

[Anoniem: 172410]

painkill schreef op dinsdag 12 februari 2013 @ 02:16:
Doet mij trouwens denken aan een verhaal over iemand welke maar 300KM kon e-mailen. Als de ontvanger verder dan die afstand zat dan kwamen zijn e-mails niet aan. Uiteindelijk ook een instelling, maar kom er maar eens achter

Dat komt natuurlijk doordat de digitale postduif dan moe wordt

Serieuzer vind ik dat wel een erg interessant fenomeen, want technisch gezien zou afstand natuurlijk niet relevant moeten zijn, tenzij je 300 kilometer point-to-point probeert te doen.

[kKaltUu]

Anoniem: 172410 schreef op dinsdag 12 februari 2013 @ 03:36:
[...]

Dat komt natuurlijk doordat de digitale postduif dan moe wordt

Serieuzer vind ik dat wel een erg interessant fenomeen, want technisch gezien zou afstand natuurlijk niet relevant moeten zijn, tenzij je 300 kilometer point-to-point probeert te doen.

ging over de ttl van de mails

waarschijnlijk was het een verhaal uit de sharktank van sharky

[bjck]

A.Kebab schreef op dinsdag 12 februari 2013 @ 03:32:
Het probleem doet zich voor op verschillende verbindingen. Een zakelijke verbinding was het snelst en daar kon ik 600KB/s van de beschikbare 1MB/s halen. Heb daarnaast nog 3/4 andere verbindingen getest die allemaal rond de 300 KB/s bleven steken waarbij sommige toch wel 2.5MB/s konden halen. Volgens mij waren de meeste verbindingen van Time Warner en eentje van AT&T.

Het is in ieder geval goed om te horen dat de afstand niet de beperkende factor is. M'n huidige aansluiting (ik wissel zo nu en dan van tijdelijke woning) heeft een shitty router met bijzonder weinig instellingen dus kan op het moment helaas niet fiddlen met de TCP windows. Wel goed om te weten dat dit eventueel effect kan hebben voor wanneer ik weer een geavanceerde router beschikbaar heb!

PS: Ik gebruik megabytes en kilobytes om de snelheden te beschrijven, voor het geval hier verwarring over is

Met TCP/IP parameters optimaliseren voor hoge(re) latency verbindingen (door afstand) kan je wel degelijk op je client machine. Je router heeft daar weinig mee van doen, is een end-to-end protocol.

Je zou ook kunnen denken aan een tunnel verbinding. Je zoekt een Nederlandse hoster van wiens netwerk je wel hoge(re) snelheden kan behalen en neemt daar een server. Dan tunnel je al je verkeer (of deel van Nederlandse prefixen) daar doorheen. Kost wel wat, je betaalt de megabits immers nog een keer.

[ Voor 11% gewijzigd door bjck op 12-02-2013 08:35 ]

[A.Kebab]

bjck schreef op dinsdag 12 februari 2013 @ 08:33:
[...]


Met TCP/IP parameters optimaliseren voor hoge(re) latency verbindingen (door afstand) kan je wel degelijk op je client machine. Je router heeft daar weinig mee van doen, is een end-to-end protocol.

Je zou ook kunnen denken aan een tunnel verbinding. Je zoekt een Nederlandse hoster van wiens netwerk je wel hoge(re) snelheden kan behalen en neemt daar een server. Dan tunnel je al je verkeer (of deel van Nederlandse prefixen) daar doorheen. Kost wel wat, je betaalt de megabits immers nog een keer.

Ik heb even gegoogled naar een custom config voor /etc/sysctl.conf. Met de volgende settings

code:

kern.ipc.maxsockbuf=4194304
kern.ipc.somaxconn=512
kern.ipc.maxsockets=2048
kern.ipc.nmbclusters=2048
net.inet.tcp.rfc1323=1
net.inet.tcp.win_scale_factor=3
net.inet.tcp.sockthreshold=16
net.inet.tcp.sendspace=262144
net.inet.tcp.recvspace=262144
net.inet.tcp.mssdflt=1440
net.inet.tcp.msl=15000
net.inet.tcp.always_keepalive=0
net.inet.tcp.delayed_ack=0
net.inet.tcp.slowstart_flightsize=4
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.icmp.icmplim=50

haal ik nu bijzonder stabiele snelheden!



In vergelijking met de oude grafiek is het verschil dag en nacht.



Ik weet nog niet hoe zich dit op andere netwerken gaat gedragen maar voor alsnog

[bjck]

De vraag waarom dit helpt is nog niet beantwoord. Blijkbaar gaat het zo beter om met verbindingen met een hoge latency (US - NL).

[ Voor 108% gewijzigd door bjck op 12-02-2013 20:01 ]

[A.Kebab]

bjck schreef op dinsdag 12 februari 2013 @ 19:56:
De vraag waarom dit helpt is nog niet beantwoord. Blijkbaar gaat het zo beter om met verbindingen met een hoge latency (US - NL).

Ja, ik ga het ook nog even testen op andere netwerken. Initieel werkte het heel goed maar ik heb nu weer wat wisselende resultaten. To be continued.

[TWeaKLeGeND]

Het ligt aan je ISP en de ISP van degene die je probeert te bereiken, niet aan de afstand. Met andere woorden, de boosdoener is winstmaximalisatie. Je kan wel de verbinding enigzins tweaken om er toch meer uit te halen dan standaard, maar dat neemt niet weg dat het aan de ISP's ligt.

[timmie1]

Hier nog een die er last van had vanaf een Verizon verbinding, Brooklyn, NY.
Niet alleen surfen maar ook Skype.

Verbinding USA: 4/4, ping lokaal 28ms
Verbinding NL: 60/6, ping lokaal 15ms

[CyBeR]

bjck schreef op dinsdag 12 februari 2013 @ 19:56:
De vraag waarom dit helpt is nog niet beantwoord. Blijkbaar gaat het zo beter om met verbindingen met een hoge latency (US - NL).

Die vraag heb ik al beantwoord in mijn eerste post.

Overigens gebruik ik

code:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 11131072
net.core.wmem_default = 11131072
net.ipv4.tcp_rmem = 4096    2097152 16777216
net.ipv4.tcp_wmem = 4096    2097152 16777216

(da's dan wel voor gigE maar op een goede langzamere verbinding moet 't ook prima zijn.)

Oh excuseer, ik zie nu dat geen linux hebt maar een BSD-variant.

[ Voor 42% gewijzigd door CyBeR op 12-02-2013 20:44 ]

[A.Kebab]

CyBeR schreef op dinsdag 12 februari 2013 @ 20:41:
[...]


Die vraag heb ik al beantwoord in mijn eerste post.

Overigens gebruik ik

code:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 11131072
net.core.wmem_default = 11131072
net.ipv4.tcp_rmem = 4096    2097152 16777216
net.ipv4.tcp_wmem = 4096    2097152 16777216

(da's dan wel voor gigE maar op een goede langzamere verbinding moet 't ook prima zijn.)

Oh excuseer, ik zie nu dat geen linux hebt maar een BSD-variant.

Klopt, ik werk op OSX. Ik ga wanneer ik klaar ben met werken eens wat prutsen met de instellingen en kijken wat het beste werkt.

[bjck]

timmie1 schreef op dinsdag 12 februari 2013 @ 20:25:
Hier nog een die er last van had vanaf een Verizon verbinding, Brooklyn, NY.
Niet alleen surfen maar ook Skype.

Verbinding USA: 4/4, ping lokaal 28ms
Verbinding NL: 60/6, ping lokaal 15ms

Wat je helaas niet weet is wat de buffer dieptes zijn en het drop mechanisme van de interface vlak voor de 'bottleneck', dus de WAN interface van je thuis router(s). Soms kan het helpen om een datastroom net onder het maximale te houden van je WAN verbinding van je provider als de uitgaande WAN interface instellingen niet zijn afgestemd op de snelheid van de verbinding waarop je provider af regelt.

Doe je dit niet krijg je een zaagtand te zien als je doorvoor snelheid vs tijd in een grafiek hebt.

[ Voor 6% gewijzigd door bjck op 12-02-2013 22:38 ]