Magyar Telekom forgalmat priorizál?

Hálózatok egyéb

Néhány hete azt tapasztalom, hogy általam karbantartott gépekre a http://koji.fedoraproject.org/koji címről Magyar Telekom szolgáltatón lógó gépre legfeljebb néhány 10 kB/s sebességgel tudok csomagot letölteni. Ugyanezeken a gépeken általában gyors az internet elérés. Viszont erről az URL-ről a gépemre gyors a kiszolgálás, de én nem is vagyok MT ügyfél.

Ami eszembe jutott:

1) A scriptemet régen írtam, az URL http és nem https kezdetű. Lehet, hogy titkosítva menne ez gyorsan, tehát lehet, hogy a 80-as portot az MT beszűkíti, a 443-ason mehet az adat gyorsan? (Közben kipróbáltam a https-t, nem segített.)

2) A koji.fedoraproject.org domain mögött több gép van, s a panaszolt gépek távoli, szűk sávszélességű mirrorokhoz csatlakoznak. Ennek ellentmond, hogy a nyár végén cserélték a Fedora infrastruktúráját, új szerverek kerültek beüzemelésre, gyorsabbak a kiszolgálók. Aztán miért mindig csak Magyar Telekom esetén?

3) MT irányból sok fertőzött gép DDoS-olni próbál mindent, ami él és mozog, így esetleg a Fedora kiszolgálója limitálja a sebességet, ha MT felől jön a kérés.

4) A Magyar Telekom valami más szempont alapján diszkriminálja a forgalmat, s kínosan kis sávszélességet ad neki.

Számlatartozás, effélék nincsenek egyik ügyfélnél sem, elletve más helyről gyors a letöltés.

Az általam tippeltek közül melyik lehet, vagy, ha egyik sem, mi a megoldás?

  • 1201 megtekintés

Fura, mert 30 ms-nál nagyobb időket már csak külföldön látok. Összehasonlítottam a saját gépemről indított traceroute időkkel, elég hasonlók. Azaz külhonban látok 120 ms körüli időket, de a Telekom mögötti gépen éppen úgy, mint nálam. A letöltés nálam mégis MB/s nagyságrendű sebességgel jön, míg a Telekom mögötti gép esetében most épp 88 kB/s. Miközben az az előfizetés talán 100 Mb/s-os, tehát simán kellene hozni a 10 MB/s-ot is akár.

Azt a bevezetőben nem írtam, de két teljesen független, egy budapesti és egy vidéki MT előfizetésen lógó gép esetében is pontosan ez a jelenség.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( cadmagician | 2020. 12. 09., sze – 21:01 )

Hat a forgalmat szabalyzo eszkozok is lehetnek okosak. Pl pinget hatrebb soroljak streameket jobban stb. Nalunk Pl tcp ack kesett.... kellett a peerel valaszt kuldenunk. Ekkor jott az ack is meg a valasz is. Azonnal

Aki másnak vermet ás, az stack pointer.

( cadmagician | 2020. 12. 09., sze – 21:01 )

Hat a forgalmat szabalyzo eszkozok is lehetnek okosak. Pl pinget hatrebb soroljak streameket jobban stb. Nalunk Pl tcp ack kesett.... kellett a peerel valaszt kuldenunk. Ekkor jott az ack is meg a valasz is. Azonnal

Aki másnak vermet ás, az stack pointer.

( cadmagician | 2020. 12. 09., sze – 21:01 )

Hat a forgalmat szabalyzo eszkozok is lehetnek okosak. Pl pinget hatrebb soroljak streameket jobban stb. Nalunk Pl tcp ack kesett.... kellett a peerel valaszt kuldenunk. Ekkor jott az ack is meg a valasz is. Azonnal

Aki másnak vermet ás, az stack pointer.

( cadmagician | 2020. 12. 09., sze – 21:01 )

Hat a forgalmat szabalyzo eszkozok is lehetnek okosak. Pl pinget hatrebb soroljak streameket jobban stb. Nalunk Pl tcp ack kesett.... kellett a peerel valaszt kuldenunk. Ekkor jott az ack is meg a valasz is. Azonnal

Aki másnak vermet ás, az stack pointer.

( cadmagician | 2020. 12. 09., sze – 21:02 )

Hat a forgalmat szabalyzo eszkozok is lehetnek okosak. Pl pinget hatrebb soroljak streameket jobban stb. Nalunk Pl tcp ack kesett.... kellett a peerel valaszt kuldenunk. Ekkor jott az ack is meg a valasz is. Azonnal

Aki másnak vermet ás, az stack pointer.

( cadmagician | 2020. 12. 09., sze – 21:03 )

Buzi ipad. Bocsi

Aki másnak vermet ás, az stack pointer.

( E-Medve v | 2020. 12. 09., sze – 21:18 )

Szerkesztve: 2020. 12. 09., sze – 21:20

Ahogy én látom, a megadott FQDN round robinnal, de 2 darab USA IP-re old fel. Simán lehet, hogy elfogy az MT (vagy valamelyik igénybe vett tranzitszolgáltató) sávszélessége USA irányba. A lassulást tudod időponthoz kötni? Két időpontot lenne érdemes megnézni: reggel/délelőtt (USA keleti part alszik), éjfél után (az EU alszik)

Amióta EU tagok vagyunk, én is alszom éjfél után. :) Jó, tudom, lehet erre scriptet írni, de ezek Magyarországon lévő desktop gépek, így nehezen kivitelezhető, hogy a gazdájuk hagyja bekapcsolva a gépet egész éjszaka.

Ilyesmire szerinted MT ügyfélszolgálattól kaphatok értelmes választ, megoldást, vagy szinte biztos, hogy a takarodjak az anyámba nyájas, udvarias megfogalmazásában lesz részem?

Szerk.: Korábban mindig jó volt, most meg soha.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

erősen csodálkoznék, ha a DT USA irányú kapacitása elfogyna :-)

Hogy előremutatót is mondjak, kiváló lehetőség ilyen feltételezések igazolására a speedtest-cli
amivel le tudod kérni a speedtest serverek listáját, tudsz országra grep-elni, és tetszőleges szerverre tesztelni.

Igaz, hogy nem olyan pontos mint egy windows/html5 kliens de azért össze tudod vele hasonlítani, hogy mennyivel lassabb egy USA server
egy DE v FR servernél.

No, hogy én is mondjak előremutatót. Igaz, hogy nem vezetékes MT, de T-Mobile mobilnettel csináltam 2 db speedtest-et, mindkét esetben Raleigh irányába: letöltés jellemzően 1 Mbit/sec, feltöltés jellemzően 20 Mbit/sec

Szerk: próbáltam egy közeli egyetemi tükörről letölteni, de úgy se ment 1 Mbit/sec fölé.

igaz, nem Telekom, hanem Telenor mobilnet, de szinte kivétel nélkül azt tapasztalom, hogy a letöltési irány nagyságrendekkel rosszabb a feltöltési iránynál.
Ennek az oka -szerintem- az, hogy TDD rendszert használnak, azaz letöltéshez és feltöltéshez is van dedikált időrés (ha nem is ugyanannyi, de mondjuk 60:40 arányban) mivel a userek nagy része letölt, az elfogy a feltöltés pedig nem. Ez persze csak mobil hálózatra igaz így (nem feltétlen a cellakapacitásra, uez igaza az azt kiszolgáló gerincre is)

Mindenféle paraméterezés nélkül a „lassú” gépen:

Download: 153.07 Mbit/s
Upload: 5.78 Mbit/s

De azt tudtam eddig is, hogy nem általában vacak a netkapcsolat, csak valamiért olyan, mintha a Telekom limitálná a Fedora build szervere felől a sávszélességet.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nekem amíg telekom előfizetésem volt, az usa beli szerverek elérése problémás volt. Volt olyan szerver, amit pingelni ugyan lehetett, de ennél nagyobb csomagok nem nagyon jöttek át. Tisztára mint a betárcsázós időkben... 

Nem tudom, miért van, hogy a legdrágább internet-szolgáltató spórol a legtöbbet a transzatlanti forgalmon.

Megváltás volt, mikor a Digi elkezdett felénk is terjeszkedni. Az pedig külön megér egy misét, hogyan korábban miért nem engedték őket behúzni az optikát...

Jó ötlet, csináltam flood pinget:

--- koji.fedoraproject.org ping statistics ---
1057 packets transmitted, 891 received, 15.7048% packet loss, time 13953ms
rtt min/avg/max/mdev = 121.141/124.350/150.924/2.762 ms, pipe 13, ipg/ewma 13.213/125.039 ms

Ugyanez az én egyébként kevesebb, mint fele sebességű netkapcsolatomról:

--- koji.fedoraproject.org ping statistics ---
583 packets transmitted, 576 received, 1.20069% packet loss, time 8151ms
rtt min/avg/max/mdev = 110.029/112.592/125.359/2.156 ms, pipe 11, ipg/ewma 14.004/112.689 ms

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Valamit nem értek, de nem vagyok hálózatos szakember. Ha ott van baj, akkor miért van az, hogy csak MT hálózatból lassú, míg nekem másik szolgáltatótól gyors? Ha a külföldi messzeségben rossz valami, akkor nem kellene nálam is használhatatlanul lennie? Budapestről nézem, csak nem MT hálóból.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ennyire én se mentem bele a hálózatokba. Szerintem egy autós hasonlat elég lesz. Tegyük fel, hogy te és egy barátod el akartok menni két külön autóval, de ugyanabba a távolabbi városba. Ketten két különböző navigációt használtok online frissítéssel. Ha ugyanakkor indultok is, akkor se biztos, hogy ugyanazt az útvonalat fogja javasolni mindkettőtöknek a navi.

Digiből telia felé ment a trace, rackforestből szintén.

Telekomból viszont másfelé, egy DT-s ip után egyből egy cogentco.com-os host volt. valószínű, hgy ott lehet valami DT és cogentco között.

Ez nem olyasmi, amit neked kell megoldani :)

A legegyszerűbb, ha T-s előfizető a T-nél bejelenti, hibajegy alapján majd mondanak rá valamit.

Primitív. Nem tud komplex mondatokat értelmezni, általában az első kérdésére adott válasz után már igen/nem-játékot játszik, felbaszva ezzel a gyors hibabejelentésre számító kedves ügyfél vérnyomását. 

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ja, 20 és 21 végű. Nem is néztem, hogy két cím tartozik hozzá.

Na ez az, ami nem normális. Ugyanez tőlem így néz ki:

ping -f koji.fedoraproject.org
PING koji.fedoraproject.org (38.145.60.21) 56(84) bytes of data.
.........^C 
--- koji.fedoraproject.org ping statistics ---
1138 packets transmitted, 1129 received, 0.790861% packet loss, time 15239ms
rtt min/avg/max/mdev = 109.755/112.566/132.550/2.222 ms, pipe 12, ipg/ewma 13.403/112.746 ms

1 % alatti a csomagvesztés. De Telekom hálózatból én is nagy csomagvesztést mértem. Ez mitől van? Alacsony TTL?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jogos, mert nem vártam meg a választ a végére.

ping -c 1000 -f koji.fedoraproject.org
PING koji.fedoraproject.org (38.145.60.20) 56(84) bytes of data.
.           
--- koji.fedoraproject.org ping statistics ---
1000 packets transmitted, 999 received, 0.1% packet loss, time 13816ms
rtt min/avg/max/mdev = 112.261/115.184/132.329/2.670 ms, pipe 11, ipg/ewma 13.829/116.055 ms

De a 15.7 % MT hálózatból nem emiatt volt. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Imént tesztelve Telekomos (optikai) hálózatból:

ping -c 1000 -f koji.fedoraproject.org

PING koji.fedoraproject.org (38.145.60.21) 56(84) bytes of data.
--- koji.fedoraproject.org ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 13537ms
rtt min/avg/max/mdev = 119.175/120.323/132.457/1.673 ms, pipe 11, ipg/ewma 13.550/119.694 ms

ping -c 1000 -f koji.fedoraproject.org

PING koji.fedoraproject.org (38.145.60.21) 56(84) bytes of data.
--- koji.fedoraproject.org ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 12683ms
rtt min/avg/max/mdev = 119.174/120.216/135.176/1.781 ms, pipe 11, ipg/ewma 12.696/119.877 ms

Ugyanez most vizsgálva:

ping -c 1000 -f koji.fedoraproject.org
PING koji.fedoraproject.org (38.145.60.20) 56(84) bytes of data.
......................................................................................        
--- koji.fedoraproject.org ping statistics ---
1000 packets transmitted, 914 received, 8% packet loss, time 12883ms
rtt min/avg/max/mdev = 119.071/120.623/131.686/1.349 ms, pipe 11, ipg/ewma 12.896/120.664 ms

ping -c 1000 -f koji.fedoraproject.org
PING koji.fedoraproject.org (38.145.60.20) 56(84) bytes of data.
.............................................................................         
--- koji.fedoraproject.org ping statistics ---
1000 packets transmitted, 923 received, 7% packet loss, time 13184ms
rtt min/avg/max/mdev = 119.405/120.258/123.022/0.596 ms, pipe 11, ipg/ewma 13.197/120.537 ms

Most van packet loss is, ugyanarról a hálózatról próbálva.

Mellesleg van egy VPS-em USA-ban, és egy ideje észrevettem, hogy időnként elég lassan tudom elérni (nem válaszidő, az a szokásos valahol 150-200 ms között, hanem sávszélesség).
Nem mentem utána, hogy konkrétan mennyire, de feltételeztem, hogy olcsó VPS lévén ez ilyen (bár egyébként meglehetősen korrekt szolgáltatás)...
...viszont most elkezdtem gyanakodni, hogy a Telekom is lehet ludas ebben...

Valóban lehet némi szávszélesség limit USA felől, Telekom irányában...
...és https protokoll feletti kommunikáció esetén is érzékelhető egyébként.

( p2pking | 2020. 12. 10., cs – 12:10 )

Finneknel es hollandoknal, valamint nemeteknel levo gepeket is van, hogy nehezen erem el telekom halozatbol. Olasz dc csak neha elbont, sebesseg problema az nincs.

SSH is neha gyok ketto, vagy durvan alkalmaznak limitet, vagy tulterhelt a kozponti rendszeruk, vagy csak siman keves a kulfold.

Peldaul 1080p streamet a finn datacenterbol lehetetlen telekom halozaton nezni. Digi eddig ugyanazt hozta jol. Allitasuk szerint 300Gbps kapcsolatuk van osszesen kifele tobb tranzituton.

Osszegezve , szerintem nem vagy egyedul, csak valoszinuleg aki csak tud nem telekomozik...

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

( SPYFF v | 2020. 12. 10., cs – 12:17 )

Szerkesztve: 2020. 12. 10., cs – 12:29

Ilyen magas RTT esetén ha kevés a bufferméret (pl. kevés hop van közted meg a cél között) nagyon könnyen előfordulhat akkora under utilization. A TCP sosem lesz képes kihasználni a neki jutó sávszélességet. A másik út felé lehet talál egy nagyobb bufferű routert és így képes felmenni egy jó sávszélességig. Speedtest sokat nem fog mondani, hacsak nem nagyon közel van a fedorás címhez. Packet loss gyors pingnél mindig lesz (Ctrl+C-kor még lesz pár ICMP echo reply in-flight) ez nem probléma, de a 10-13% loss már igen, ezt egyik TCP sem tolerálja, ekkora RTT esetén meg főleg nem. A fedora szerverei ha BBR TCP-t használnának, úgy lehet hogy nagyobb lenne a svászélesség, az jól tűri a kis buffereket, nagy RTT-ket és valamennyi loss-t is.

Ha elkezdesz pingelni, majd ráindítasz egy letöltést, mennyivel ugranak meg a ping RTT-k és a loss-uk?

szerk.: érdemes olyan pinget indítani, hogy kb. 0.1 másodpercenként menjen egy csomag, ne túl lassan, hogy látszódjon a mintázat a lossban és válaszidőkben, de ne is legyen flood, hogy szélsőséges esetben megfojtsa a TCP-t.

( zitev v | 2020. 12. 10., cs – 20:45 )

Szerkesztve: 2020. 12. 11., p – 08:21

Nézzétek már meg mtr-rel is, hátha ad valami plusz információt!

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Digitol nezem most. Ma valami eszetlenul be van lassulva szinte minden kulfoldi irany nekem.

Yahoo, Finnek fele peldaul. London, ami nem itt megy az teljesen jo, ugyanakkor masik dc szinten londoni reszen van 50-70% loss, de a sebessegen ez nem latszik.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

( gheja | 2020. 12. 10., cs – 22:18 )

Csináltam pár tesztet Telekom (ex-GTS, ex-Interware), Invitech, AWS eu-west-1 és AWS us-west-1 hálózatból:

https://pastebin.com/raw/L4mKzFry

Csak a T-nél látok packet losst, így nekem nagyon úgy tűnik, hogy megint a náluk lesz valami. Tapasztaltam már hasonlót, órákon keresztül fennált, aztán egyszer csak helyrejött.

Illetve beállítottam egy RIPE Atlas mérést Telekom, Digi és néhány random külföldi helyről (óránként, 15 ping, egy hétig, hamarosan indul), hátha látsz valami érdekeset:

https://atlas.ripe.net/measurements/28357309/#probes

( Wooody | 2020. 12. 11., p – 20:03 )

Szerintem, "külföld" a probléma

Digi JDownloader Updates ...

Download Updates...
Downloadspeed: 33,81 KB/s, Time left: 30m:28s

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

Nekem sokáig jó, majd úgy tűnik, már az USA-ban egy domain név nélküli 38.32.106.90 címnél megugrik a packet loss. Ami viszont érdekes, hogy nem telekomos hálózatból más irányba megy a csomag, és úgy gyors, alig van csomagvesztés.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az az érdekes, hogy a hup felé is  50% a veszett csomag (ha jól látom bix-en van).

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek