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?
Hozzászólások
Traceroute mit mutat?
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:]' <<<locsemegeLOCSEMEGE
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.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.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.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.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.Ez van ha a Telekom megeszi az ack-t és többször kimegy ugyanaz a TCP csomag :D
Buzi ipad. Bocsi
Aki másnak vermet ás, az stack pointer.Semmi baj, azt valahogy éreztem, hogy nem szándékos flood. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ilyeneket en szoktam produkálni, és azt se tudom hogyan. :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
A HUP olyan fasza, hogy ennyi fejlesztés után még mindig nem sikerült megoldani egy sor js kóddal, hogy gombnyomás után a gomb legyen letiltva...
elvan foglalva a ujhozzaszolas bug keresesevel!! :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
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:]' <<<locsemegeLOCSEMEGE
Ha nagyon ráérsz, akkor vetethetsz fel hibajegyet, de a szerződésben a garantált sávszél általában csak a szolgáltató hálózatára vonatkozik. Hogy azon kívül milyen sebesség érhető el - akár még csak országon belül is - már más tészta.
Igazából fogalmam sincs, mi az oka. Csak az tűnt fel, hogy két olyan gépen tapasztalom ezt, amelyeknek Magyar Telekom a szolgáltatójuk. Nálam hasít ugyanonnan a letöltés, de nekem nem telekomos előfizetésem van.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
újabban már kéne megadni nem csak hálózaton belüli vállalást, de hazai sőt külföldit is - ha jól tudom. (mintha láttam volna ilyet NMHH "űrlapon")
Ugyanaz lesz, mint a mobilnál a garantált 0/0 :-D
Vagy országonként lesz garantált megadva külföld esetén?
off
Divide by zero :)
/off
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
mivel a garantált sávszélesség nem a remote endpoint-hoz garantált, hanem adott IX-hez, így szerintem egészen könnyen lehet olyan vállalni, hogy
EU IX esetén y mbps
ázsiai IX esetén y mbps
USA IX esetén z mbps
egyéb n mbps
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:]' <<<locsemegeLOCSEMEGE
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...
Éppen most néztem vezetékes Telekom elérésről, van rajta csomagvesztés ha esetleg érdekes lehet
https://imgur.com/hlPg5O3
Jó ötlet, csináltam flood pinget:
Ugyanez az én egyébként kevesebb, mint fele sebességű netkapcsolatomról:
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Trace is érdekes lehet. Ha megnézed, akkor a vége felé lesz itt a loss a dologban.
https://imgur.com/0uPjJcx
Itt az nem világos, hogy MT hálózatból mi az a 15.7 % csomagvesztés, míg tőlem, másik szolgáltató hálózatából ez 1.2 % volt csupán.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nézd meg a 2 traceroute-ot. A cogentco.com hálózatában valami elkavarva ezek szerint (a bio02-dca01 között). A Digi irányából például 0 a loss.
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:]' <<<locsemegeLOCSEMEGE
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.
Tényleg nem ismerem, hogyan történik a forgalom route-olása, de itt nincs balancing, optimalizálás?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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.
Ha szerencséje van, akkor Vandán és a Level1-en túljut a probléma. :-)
Vanda intézkedik és önállóan átkonfigurálja a border gatewayt, azonnal lesz egy új gyorsabb útvonal az AS-ek között. Közben peering szerződést is köt.
Vanda egy Elisa beszélgetés szimulator szintjén sem tudott túljutni, de arra jó volt, hogy ne kelljen élő erőt fizetni a vonal végén.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Szerencsére nekem még nem volt vele dolgom személyesen, de hallottam már róla barátoktól/ismerősöktől. :-)
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
egy "normál" user esetén szerintem mosolyognak egy jót, és elengedik a bejelentést.
Ha bérelt vonali user problémázik hasonlón, akkor talán nekifognak...
Én is ezt latom telekomrol.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Messzemenő következtetéseket a sávszélre nézve levonni abból, hogy flood pingre csomagvesztés van nem érdemes. Simán lehet, hogy egyszerűen csak az abúzus szűrő valakinél vastagabban fog.
Csináltam én is egy klasszikus ping-et 5 percen át, mindkettőre 11% és 13% loss.
Már hogy értve mindkettőre? MT hálózatból? Úgy lenne jó, ha MT-ből, meg másik hálóból is lenne teszt.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
A két IP-re néztem külön-külön MT hálózatból (T-Mobile) 11% és 13% a loss. Digi-n ugyanezen idő alatt 0%.
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:
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:]' <<<locsemegeLOCSEMEGE
Ha nem használod a "-c" opciót flood-nál, akkor valamennyi loss mindig lesz. :-)
Jogos, mert nem vártam meg a választ a végére.
De a 15.7 % MT hálózatból nem emiatt volt. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Imént tesztelve Telekomos (optikai) hálózatból:
Ugyanez most vizsgálva:
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.
Digi illetve Invitel felől 0% loss, ~105-110ms átlagos rtt.
Köszönöm a tesztet. Akkor ezek szerint időszakos. Kéne egy európai mirror.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
írországból megnéztem, ott helyi (értsd: irishdomains.com) szerverre mutatott
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.
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.
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
Segíthetnél legalább értelmezni, amit írsz. Nem vagyok hálózatos szaki, így nem mondanám, hogy fél szavakból is értem, amit írsz.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Bocsi. Tehát mtr-paranccsal (vagy win alól a winmtr-el) is csekkold le a végpontot, ez kb. egy ping/traceroute kombináció, amivel pl a packet loss-t könnyű felderíteni egy szakaszon.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Jé, tlnyleg van ilyen parancs, még fel is van telepítődve. :)
Ne sértegess!
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
ae3-4.RT.DPX.BUD.HU.retn.net
eddig villam minden nalam, itt par nagysagrendet valtozik a dolog.
Every single person is a fool, insane, a failure, or a bad person to at least ten people.
Telekom hálózatból, vagy máshonnan?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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.
Digitől nálam is. Tegnap este körül kezdődött.
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
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:]' <<<locsemegeLOCSEMEGE
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