-
Fototrend
DIGI internet Gyakran Ismételt Kérdések
(Kattints az Összefoglaló kinyitása feliratra!)
Utolsó frissítés: 2024. február
Aktív témák
-
válasz
tobi''
#84093
üzenetére
Nem teljesen ország specifikus egyébként, hogy van-e vagy nincs. Tudok neked mutatni nem egy olyan ONT vendort (nem csak kínait), ahol még a legfrissebb 2020 júliusi firmware-ben sincs még baby jumbo támogatás sem a GPON interfészen... Mi sem tudtuk bevezetni többek között emiatt.
-
válasz
tobi''
#84083
üzenetére
Azt a kérdést kellett volna feltenned, hogy a Digi optikán támogatja-e a baby jumbo frame-et, és akkor rögtön megkaptad volna a megfelelő választ: nem. Egyébként a Telekom sem.
A jól működő MSS clamp-hez a WAN MTU-t (ebben az esetben a PPPoE kapcsolatét) kell helyesen beállítani, utána jól fog működni. Ha nálad 1492 bájtos MTU mellett szarul működik, akkor reszelgetni kéne még picit a pfsense-et, vagy más probléma van.
-
válasz
tobi''
#84055
üzenetére
A 8 bájt a PPPoE overhead. Telekomnál is Diginél is ennyi, a valódi MTU-d így 1492 bájt.
A Windows-os PING uye minden overhead nélkül adja meg a méretet, tehát ha a -f -l 1472-t használod, akkor az 1500 bájtos IP csomagot jelent (20 bájt IP és 8 bájt ICMP overhead nincs benne az 1472-ben).
PPPoE mellett az MTU-d 1492 bájt, tehát a windows-os ping alkalmazásnál -f -l 1464 -et kell megadni.
-
válasz
TeeJay
#84022
üzenetére
Egy PON port az OLT-n általában maximum 128db ONT-t tud kiszolgálni. A 128-at nem tudod túllépni, ha megpróbálod akkor az ONT nem fog tudni range-elni (nem épül fel a PON OMCI kapcsolat). A 64-et túl lehet lépni abban az estben ha van elég tartalék a hálózatban, de azt látni kell, hogy ha a hálózat 64-es osztásra van méretezve (elsősorban a távolság miatt), akkor nem tudod egyetlen egy ügyféllel sem túllépni azt, mivel ahhoz újabb osztást kell berakni, amivel így kifutsz a tervezett optikai büdzséből (értsd: nem lesz elég a jelszint ha ezt a plusz utólagos osztást berakod). Az osztási számot alapvetően két dolog befolyásolja: 1. a távolság 2. a tervezett kapacitás. Például csak gigabites előfizetések mellett elég bátor dolog 128-as osztásra méretezni, de persze az is igaz, hogy a 128-as tervezési szám nem jelent effektíve 128 valódi előfizetőt.
A TV-re ez nem vontakozik, az külön hullámhosszon megy, és nagy teljesítményű EDFA lézerrel állítják elő, amit több ezer felé el lehet osztani. Többek között ez is előnye az IPTV-vel szemben. Például ha totlálisan bekotlik az OLT és nincs internet meg telefon, TV ettől még lesz
Ennél picit részletesebben olvashatsz erről itt: [link] nemrég frissítettem a cikket, más érdekesség is van benne. A cikk születéséhez képest a PON jövője némiképp más irányt vett, azt majd később fogom átírni. -
válasz
TeeJay
#84020
üzenetére
Pont erre céloztam, hogy ha szint probléma lenne, azt látnák belülről is. Az ONT persze lehet szar, de erre kicsi az esély. Ha pedig más központi hiba van, akkor kint az ügyfélnél nincs mit csinálni, minek menjen ki? Bentről nyugodt körülmények között nézegetheti a KPI-okat, és rájöhet a hiba okára.
-
"De biztos én nem értek hozzá..."
Minden paramétert látnak (a jelszinteknél sokkal többet), a kérdés inkább az, hogy hozzáférsz-e kompetens szakemberhez, aki ezeket értelmezni is tudja majd a szolgáltató oldaláról. A lakásra kiküldött szerelő a legkevésbé látja át a rendszer szintű működést. Maximum mér szintet (de ezt látnák a központi oldalon is, ha ezzel lenne gond), újrahegeszti a kábelt ha szükséges, kicseréli az ONT-t ha dölgődik. Ennyit tud tenni a szerelő. Összetett köponti hibát nem tud diagnosztizálni.
-
#83774
dchard
veterán
YellowFlash
#83773
válasz
YellowFlash
#83773
üzenetére
Hát ilyen sem történik minden nap...
A holland peering partnerünk megerősítette, hogy náluk is volt több rövid flap a Level3 irányába, jelentős csomagvesztéssel. Ez az elmúlt 2 napból is sok mindent megmagyaráz...
Állítólag már megjavították, de azért a következő órákban még lehet meglepetés.
-
válasz
viktorhu
#83681
üzenetére
Azt hiszen kis további magyarázatra van szükség:
1. A QoS a GPON hálózatban L2-n van megoldva, ezt az OLT-ben konfigurálják, és az ONT-be ez az úgynevezett OMCI protokollon keresztül kerül alkalmazásra. A PPPoE kapcsolatnak ehhez semmi köze nincs. A PPPoE kapcsolat csak az IP kapcsolat felépítésében (IP cím, maszk, átjáró, névszerverek) játszik szerepet.
2. Az ONT-ben az éppen aktuális szolgáltató VLAN mappingjét (melyik VLAN-on jön a PPPoE, IPTV, IP telefon stb., illetve hogy melyik VLAN milyen prioritású) több féle módon is be lehet tölteni: az egyik, hogy az ONT-ben lévő alap mappinget használja a szolgáltató, a másik hogy XML profilt tölt le az ONT, de akár az első csatlakozáskor TR-069-en is történhet ennek a provisioning-je. Nagyobb megrendelés esetén a gyártó kérésre egyedi konfigurációval is tudja szállítani az ONT-ket.
3. Az effektív sebességet általában az OLT-n állítják be, de az az ONT úgynevezett UNI portján kerül alkalmazásra. Ebből is látszik, hogy az OLT és az ONT-k szerves logikai egységet alkotnak, ha úgy tetszik az ONT-k az OLT meghosszabbított részei, ezért sem lehet őket csere-berélni.
-
válasz
#42556672
#83219
üzenetére
"Ez egy szakmai fórum, fogalmazzunk már pontosan...."
Na igen. Természetesen szó nincs szintezésről, kevered a fogalmakat a koax világgal. Szintezni olyasmit lehet, aminek változtatható a kimenő teljesítménye. Az OLT-ben vagy az ONT-kben lévő optika nem ilyen. Az optikai hálózatot méretezni szokás.
"Ha az utolsó bekötés vagy akkor igen, nem mindegy, hogy 100m vagy 1000m a bekötés."
Egy tisztességesen méretezett optikai hálózatban is van legalább 2-3dB tartalék, tehát ha te vagy az utolsó, legtávolabbi előfizető, akkor is teljesen mindegy, hogy egy kilóméterrel több vagy kevesebb a kábelhossz.
"mi az hogy 1km kábelnél nincs jelveszteség?! "
Nincs számottevő jelveszteség. Akkora főleg nincs, ami befolyásolja a hálózat teljesítményét. Ugye az eredeti kérdés az volt, hogy maradhat-e 50 méter feltekert kábel a lakásban (például ha később majd át kell helyezni a végpontot), amire a válasz az, hogy igen, akár sokkal több is maradhat.
"64-es osztással Class C+ hálózat (32dB csillapítás mérleg) max 20km lehet"
Ez sem igaz, egy tipikus normális minőségben kiépített PON hálózat 64-es osztásnál 25-26km-t ki tud nyomni C+ optikával, és ebben már van némi tartalék is.
-
válasz
viktorhu
#83118
üzenetére
Arra próbáltam célozni, hogy ez a Telekomnál is ilyen. Dél-amerikába és a távol-keletre senkinek nincs direkt peering-je, de még csak részesedése sem azokban a vállalatokban. Ergó sem a Telekom sem más hazai szolgáltató nem tud mondjuk Peruba jobb peeringet biztosítani a másiknál. De ajánlok egy kísérletet: mondj egy általad ismert perui host nevet vagy IP-t, csináljunk traceroute-ot, és hasonlítsuk össze
-
válasz
viktorhu
#83114
üzenetére
A 200 körüli válaszidő az a Telekommal is ilyesmi lesz az tuti. Új Zéland 280-290ms. Egyszerűen a fiizkai távolság és a z elképesztően sok tranzit szolgáltató ezt teszi lehetővé.
Nyugat-európa egyébként kulturált, AM7, AMS-IX, Frankfurt stb. mind jó sebességgel jönnek csúcsban is. Nekünk AM7-ben van szolgáltatásunk, azzal van évekre visszamenő tapasztalatom, és mondhatom hogy jól működik.
-
válasz
pw12345
#82966
üzenetére
"Nem tudom ez működik-e"
Nem működik, ez csak a router és a géped közötti LAN IP címet kéri újra.
Intrudernek igaza van egyébként, és teljesen mindegy, hogy NAT-olnak-e vagy sem, és olyan sincs hogy "indiai" meg "román" stb. IP cím. És az IP címnek nem az első tagja a lényeg.
Ha a NAT-ből kikéred magad, akkor is csak annyi fog történni, hogy tudod "cserélgetni" az IP-det, és talán lesz olyan, amit a Tiktok által használt geoIP adatbázis jó országba rak, de ennek továbbra sincs semmi köze a Digihez.
-
-
#82870
dchard
veterán
Intruder2k5
#82799
válasz
Intruder2k5
#82799
üzenetére
Be kellene már írni az összefoglalóba, hogy a Digi:
1. Nem ad "román" IP-t (jelentsen ez bármit is)
2. Nem viszi románián keresztül a magyar forgalmat.
3. Az IP címek nem pudvásak.Esetleg aki ezt az ostobaságot terjeszti (mostmár nem tudom hanyadjára), azt lehetne figyelmeztetésben részesíteni.
-
-
válasz
qnadam
#82641
üzenetére
A GPON DS folyamatosan ad, szóval ha az ONT-ből kihúzod a kábelt és belenézel, akkor bizony csak a kábel/osztó csillapításától függ, hogy mekkora teljesítményű lézer fényt fogsz kapni. Szerencsére mondjuk egy 1:64-es osztás mellett -15dBm lehet a maximális jelszint amit a szemed kaphat, az nem annyira durva (bár így sem próbálnám ki).
-
válasz
TeeJay
#82623
üzenetére
"Jelre azt mondta - 30dB felett tökéletes"
Ez az OLT oldalra igaz, ha C+ modul van benne. Az ONT biztosan B+ (meg tudod nézni az alján), ott viszont -28dBm a határ, nem -30.
"Ha meg túl sok lenne az előfizető az OLT-nél kiveszik a kettes splitter és máris 64-es osztás lesz a max"
Mi is így csináljuk, annyi különbséggel hogy mi eleve 1:64-re tervezünk, és ebből lehet később 1:32-t csinálni forgalom függvényében
-
válasz
TeeJay
#82607
üzenetére
A lakótelep spéci helyzet: rövid távon nagy a népsűrűség. De láthattad, hogy senki nem gondolja a szerelőt is beleértve (nem mintha az ő véleménye különösen számítana), hogy lesz is rajta 128 előfizető. Inkább az volt a cél, hogy látják: a 64-es osztás ilyen helyen könnyen elfogy, és inkább úgy vannak vele, hogy a 64 fölött pár usert még bírjon el a technika. Ezt leírtam a korábbi hozzászólásomban is.
"-20,6dB volt ide és
-23,4dB volt vissza a jel"Hogy kábelmániát idézzem: a jelszintek megfelelőek
-
Nem megkérdőjelezve, hogy érted a különbséget: az eszközök aljára írt V és A a lehető legrosszabb körülményt feltételezi, és nem a valós fogyasztás, inkább a táp méretezése szempontjából fontos (értsd: legalább 12V/1A-s tápot kell beledugnod hogy stabilan működjön minden körülmények között. Például ha egy ONT-n van egy darab USB port, akkor rögtön számolhatsz úgy, hogy abból a 12V/1A-ből (12watt), 5V/500mA minimum az USB-é. Természetesen ha mondjuk 2 USB van rajta, vagy az USB portok magasabb áramra hitelesítettek, akkor mégtöbbet le kell vonni
-
válasz
TeeJay
#82521
üzenetére
Biztos hogy nem ilyen közepes méretű OLT-jük van, hanem a legnagyobb 16/24U-s. Egy port maximum 128 ONT-t tud kiszolgálni, de nem hinném, hogy bárki is erre tervez.
"Na most egy ilyen OLT alsó két vastag kártyája az uplink?"
Lényegében, de nem kizárólag. Általában rajtuk fut a vezérlő szoftver is, generálják az alarm-okat, SNMP-n kérdezik le őket és megy az adat a hálózat felügyeletbe, illetve a komplett L2 forwarding és QoS is bennük van. Nem véletlenül van belőle kettő
A 2x4 darab port általában 10gigás, így összesen maximum 80Gbps aggregált kapacitást lehet összerakni CWDM-mel." Nem lenne logikusabb több kissebb OLT-t alkalmazni több helyen?"
Nem. A cél a nagy agrregált OLT lokációk létrehozása. Nyilván vidéken, ahol a távolságból és a célszerűen nagy osztási arányból relatíve kisebb áthidalható távolság jön ki, ott lehet más a helyzet, de alapvetően a nagy portszám és a nagy aggregált forgalom a cél így kevesebb lokációt kell fenntartani, klímázni, felügyelni, UPS/Agregátorral ellátni, mindezt karbantartani stb.
Ahogy korábban már írtam, lehet egy komplett kártya, de lehet hogy backplane (vagy egy része), de lehet az egyik uplink kártya egyik portja is, ami a terheléselosztás miatt kihat a teljes forgalomra.
"Szóval lehet hogy a kerület másik felében jó minden nálunk meg panel telep kapott egy kisebb külön OLT-t és azon valami nem frankó?"
Simán lehet a kerületben úgy is jó, hogy csak a telepet kiszolgáló 1-2 krátya a szar egy nagy OLT-ben.
Ezt a traceroute-olást felejtsd el. Egy MPLS vagy L2 tranziton nincsenek IP hopok, nem fogsz belőlük látni semmit. Nálunk pédlául L2 kapcsolatok vannak, így a user ha traceroute-ol, akkor az első IP a központi PPPoE szerver lesz, pedig kaddig is van pár "hop"... Diginél valószínűleg az OLT PPPoE szerverét használják Radius-on, tehát a 10.0.0.1 az az OLT-ben lesz. De utána még mindig lesz egy összetett L2 vagy MPLS tranzit, amiben nem fogod látni a hopokat.
Livius:
BME-VIK? Na ne röhögtess... Normális szinten modern router vagy switch architektúrákat egyébként sehol nem oktatnak, a modern - különösen telkó specifikus - protokolok is erősen hiányosak, egyeteme válogatja hogy hol mennyire... Nincs Magyarországon normális műszaki felsőoktatás, mert abba rengeteg pénzt kéne tolni.
-
válasz
TeeJay
#82500
üzenetére
Két dolog jutott még eszembe ami kifejezetten az uplniket veri el:
1. Rouge ONT: nagyon nagyon ritkán előfordulhat, hogy egy ONT adó oldali lézere egyszerűen beragad és folyamatosan ad, nem pedig csak akkor amikor az OLT időrést oszt neki. Ezzel értelemszerűen szétveri a porton lévő többi ONT uplinkjét is. Az érzékelése nem egyszerű, de a legtöbb OLT-ben van funkció arra, hogy az egyes ONT-k adott időre teljesen lekapcsolódjanak, így egyessével meg lehet nézni, hogy melyik okozza a hibát.
2. Valaki vicces kedvében SR vagy LR optikát dugott valamelyik szabad portba, és az veri szét az uplinket (ugyanazon a frekin működik mint a GPON UL). De ez kevéssé valószínű.
A két hiba közös jellemzője, hogy csak egy porton lévő előfizetőket tud érinteni.
-
válasz
qnadam
#82503
üzenetére
Mondok jobbat: a saját részedet amit csináltatsz, kérd mindkét végén csatival, így a Digi csak a saját kábelére rak csatit, a kettőt meg egy toldóval össze tudod pattintani, és szét tudod szedni bármikor. APC SC csati kell mindenhova, erre figyelj, mert ez lényeges. Így a Diginek nem kell mást szerelnie, csak a saját kábelét (=nincs konfliktus a szerelővel). Arra érdemes még figyelni, hogy a két kábel kompatibilis legyen (belső mag és köpeny átmérő).
-
válasz
TeeJay
#82494
üzenetére
A telekom topikban már leírtam egy párszor a pékes/ácsos sztorimat, kb. ezt tudom elképzelni itt is. Egyébként kábel és kábel között nagyon nagy különbség is lehet, Vannak alacsony hajlítási sugarú spéci kábelek, amik kis túlzással azt is kibírják, ha csomót kötsz rájuk. A Digi által bekötésre használt kábel nem ilyen, ott a 30mm betartása fontos, ez nem tűnik azért betarthatatlan dolognak. A kis mértékben túlhajlított kábel nem feltétlenül törik, viszont nagy mértékben nő rajta a csillapítás.
Hadd kérdezzem meg: a telepen milyen ONT-ket szórnak? Huát vagy ZTE-t?
-
-
-
válasz
dchard
#82452
üzenetére
Közben rájöttem, hogy butaságot írtam: 7km-en -17dBm az ONT vételi szint, 15.5km-en pedig -20dBm, mindkét esetben 64-es osztás mellett. Az OLT vételi szintek -20 és -24dBm. Látszik tehét, hogy visszirányban - elsősorban az ONT-k gyengébb adási képességei miatt - kisebb jelszintek mérhetőek.
-
Ha valakit érdekelnek technikai részletek, egy pár hónapja átadott 1:64-es osztással kiépített hálózatban 7km-en -20.6dBm a vételi szint az előfizetőnél. Később lesznek 10-20km közötti ügyfelek hasonló osztással, majd mutatok adatot arról is. (OLT oldalon C+ modullal!).
-
válasz
TeeJay
#82448
üzenetére
Az első és legfontosabb a hiba méretének a behatárolása. Csak egyetlen porton lévő osztásokon vacak (egy lépcsőház például), vagy biztosan különböző portokon lévő embereknek is? Nem mindegy. Ha csak egy porton lévő ügyfeleknek szar, akkor lehet dteketor hiba, DDM hiba a modulban, AGC hiba, esetleg SFP port hiba (a cage utáni rész szarik be vagy "lötyög"). Esetleg maga a szál szar valahol, de az nagyon nagyon ritka, hogy úgy szarik be egy szál, hogy az egyik irány hibátlan, a másik meg ennyire vacak.
Ha több biztosan különböző porton lévő előfizetőnél is szar (és azonos a hibakép), akkor még mindig lehet backplane hiba a kártya és a keret között, kártya hiba (táp, szűrés, órajel stb.), de ebben az esetben már meg kell vizsgálni azt is, hogy nem uplink hibáról van-e szó. Ez utóbbi esetben jó eséllyel az OLT összes usere érzékelné a hibát, bár még itt is előfordulhat, hogy a forgalom 3-4 10gigás intrfészen megy, amiből az egyik lötyög és nincs teljes kiesés, csak a forgalom elosztásban éppen arra a 10gigás portra jutó forgalom szenved. Beállítás kérdése is, hogy l2, l3 vgay l4 hash-sel csinálják a lacp-t. Szóval számos hibalehetőség van.
-
válasz
qnadam
#82446
üzenetére
Szinte biztos hogy arra gondolnak, csak hogy abban pont az volt a cumi, hogy azon nem lehetett xDSL-t adni. Nem véletlenül hagyták abba az egészet, miután a 13. kerület belső felét jól megszivatták vele. A HYTAS valójában egy méreg drága optikai vonalkihosszabbítás, csak éppen mivel nem tudott nagy frekit (0-1, 0-2MHz kellet a DSL-nek, ráadásul duplexelve), ezért maradt az ISDN sokáig. A megoldás az volt, hogy az optika végére (mondjuk 1-2 tömbönként) mini DSLAM-et raktak, de ez akkoriban rohadt drága volt meg még nem tartott ott a miniatűrizálás, hogy lefelé jól skálázódjon.
-
#82444
dchard
veterán
headhunter
#82443
válasz
headhunter
#82443
üzenetére
A cikket olvasva azért van min mosolyogni: "optikai hálózati ADSL" Érdekelne, hogy hogyan működik az "optikai ADSL"
-
válasz
M_AND_Ms
#82421
üzenetére
12.900 volt csak az ADSL alapdíj (telefon nélkül), a 384/64kilobitért, ilyen Siemens modemmel: [link]
Érdemes megfigyelni hogy ezen még volt ATM port, és az ethernet is 10megás. 3-4megabites csomag után cserélték, mert kiderült róla, hogy nem egészen képes kihasználni a G.DMT 8 megabites elméleti maximumát
Utána jött a Dialcom, ami elindított a telekommunikáció útján (kinyerhetőek voltak belőle a vonal diagnosztikai adatai, ha nem is mind de néhány). -
válasz
TeeJay
#82107
üzenetére
Bel-óbudáról nem tudsz valamit? Évekkel ezelőtt ugyanaz volt az ígéret, hogy ha a kerületek légkábelezhető részével elkészülnek, utána a 2-es fázis lesz a nem légkábelezhető rész. De ebből még semmi nem történt meg, ráadásul jele sincs a dolognak. AZ utca végében 10 éve ott vannak a panleban, de ennyi idő alatt sem jött közelebb a hálózat vége.
-
válasz
TeeJay
#81619
üzenetére
Port hiba, eszköz hiba, a friss OLT-n ütemezési/beállítási hiba. De láttunk már fúrcsa refelxió miatt széteső uplinket is, miközben a DL frankó volt. A PON portban lévő modul detektora is lehet hibás, akkor szintén az uplink fosik be. Tehát bőven van több reális lehetőség is. Be kell jelenteni, és nem engedni lezárni.
-
#81533
dchard
veterán
MasterMark
#81531
válasz
MasterMark
#81531
üzenetére
Maradjunk annyiban, hogy van ilyen ember, de nem hozzáférhető, azt hiszem érthető a dolog
-
#81444
dchard
veterán
MasterMark
#81438
válasz
MasterMark
#81438
üzenetére
"De egyébként ez publikus tartományból van, nem? Miért gondolták jó ötletnek, hogy onnan vesznek címet vajon."
Pontosan....
-
#81437
dchard
veterán
MasterMark
#81434
válasz
MasterMark
#81434
üzenetére
Azt én sem hiszem, hogy órákig állt (a felépítéséből fakadóan), de azt el tudom képzelni, hogy egy szolgáltatónál vagy interkonnekt partnerénél lévő routing/forwarding hiba miatt az 1.1.1.1 cím elérhetetlen volt egy adott előfizetői csoport szemszögéből (ugye mit jelent az, hogy "állt"...).
De mondok mást: Huawei 4G CPE-kben (konkrétan kettőben én fedeztem fel ezt a hibát), az indoor-outdoor unit-ok hibásan 1.1.1.1 és 1.1.1.2 IP-n kommunikáltak, ezért egyetlen kliens sem tudta elérni a Cloudflare DNS-ét ezek mögül az eszközök mögül. Ha LAN mögül pingeled, az 1.1.1.1-re a CPE válaszolt...
Ezért is érdemes több címet használni több szolgáltatótól. Nálam is az 1.1.1.1 a preferált, de van még a routerben másik 6 cím is
-
válasz
qnadam
#81323
üzenetére
Ez az egész történet baromi egyszerű: akarsz kétszer annyit fizetni a szolgáltatásért ÉS várni 2-3-szor annyi időt, mire odaér hozzád csak azért hogy el legyen ásva? A többség nem. A probléma az, hogy ezt nem az önkorminak kéne eldöntenie, hanem az embereknek. Lehetne például "konzultálni" erről...
Ha a mucsi villanytszerel színvonalat sikerülne olyanná varázsolni, mint ahogy nálunk kinéz (optika, koax és villany egy oszlopon), a régi tróger matávos/postás oszlopsort meg eltűntetni, akkor teljesen vállalható lenne a dolog esztétikailag is.
-
válasz
qnadam
#81312
üzenetére
Nálunk az egész környéken - és ahol eddig Magyarországon jártam általában - mindig a magyar telekom trógerolása miatt néz ki úgy az utcakép, mint ha indiában lennénk
Persze lehet azt mondani, hogy villanyoszlophoz képest 2/3 magas, viszont közel fele olyan sűrűn rakott oszlopok meg a 20-30 évnyi szir-szar technológia együttesét ne kérjem rajtuk számon, de én azért mégis csak megteszem. Jól emlékszem arra, hogy ezek miatt a gyökerek miatt tiltotta le jónéhány önkormányzat a légkábelt majd két évtizedre (volt persze dilettáns térkő-mániás is közöttük). A közvetett kár amit okoztak Forintban és erkölcsileg is felbecsülhetetlen. Lehet légkábelezni kulturáltan, csak nekik nem megy -
#81074
dchard
veterán
xeon forever
#81072
válasz
xeon forever
#81072
üzenetére
Ha 6 órád van otthon alvással együtt, akkor ez lesz a legkisebb problémád
-
#81067
dchard
veterán
xeon forever
#81066
válasz
xeon forever
#81066
üzenetére
3100-ért? A "programozóknak" van igazuk...
-
-
válasz
4Grider
#80924
üzenetére
Fogalmi zavarban vagy: nem az a kérdés, hogy az otthoni neted mekkora rendelkezésre-állással működik, hanem hogy mennyi az amennyit garantálnak, ami után ugye komolyabb helyeken jön a kötbér, kártérítés stb. Ez nem azt jelenti, hogy lesz is évi 5 nap kiesés, csak annyi, hogy ennyi idő után leszel jogosult mondjuk kártérítésre.
-
válasz
Kicsimix
#80778
üzenetére
Dehogy egyezik. Pont arra céloz, hogy ugyanazért gondolja tévesen a speedtest, hogy debrecenben vagy, mint amiért a vizuális traceroute-od is: szar a geoip data, amiből mindkettő dolgozik. Ennek semmi köze a Digi-hez. Használd kézzel a budapesti szervereket, ennyi a megoldás.
-
#80774
dchard
veterán
MasterMark
#80771
válasz
MasterMark
#80771
üzenetére
Az én publikus IP-mre is azt írja, hogy Debrecen, ettől még csak tudom, hogy nem debrecenben vagyok
A cégnek akitől a tartomány van, viszont debreceni a telephelye.inetnum: 178.164.206.0 - 178.164.206.127netname: DIGI-1descr: Debrecen Fibercountry: HUDe ez már tényleg az N+1-edik... Jelentse csak be, a világért nem fosztanám meg a munkában megfásult kollégákat egy kis szórakozástól.
-
válasz
Kicsimix
#80768
üzenetére
Harmadszorra írom le: nem kell hozzá semmiféle bennfentesség. Megnézed a válaszidőt és kész. Bárki végezhet összehaosnlító mérést bármilyen külfödi irányba, világosan látszik, hogy hol lép ki az országból a csomag.
De tudod mit? Az itteni szájkarate helyett jelentsd be, hadd legyen az átviteltechnikának egy jó napja, amikor majd meglátják a hibajegyben a képeidet az OLT IP-vel debrecenben... (már ha előtte egy közepesen képzett technikus ki nem szortírozza..., a mérnökóra ugyanis elég drága).
Tannenbaum bácsit tudom neked ajánlani: [link] A maga 900 oldalával elég pongyola, de valami azt súgja, lesz benne új információ a számodra
-
válasz
Kicsimix
#80763
üzenetére
"Nem hinném, hogy romániában mutatná."
A "bb01.budapesta.rdsnet.ro" cím az összes képeden romániában van, miközben budapesten van. Erről ennyit.
"Csak az a fránya 10 év.. Amíg jó volt.. Az sok idő ám."
Pont annyi, amennyi idő alatt egy jobb router tápjában is kiszárad a kondi. (csak egy példa a számos lehetőség közül). Az is megtörténhet, hogy a kevésbé terhelt FTTB-ről átkerültél egy terhelt FTTH portra. Csúcsidőben nálam is "csak" 5-600megabit van akármelyik szerveren mérek. Ettől még nem megy semmi debrecenbe, se romániába...
-
válasz
Kicsimix
#80757
üzenetére
Na mégegyszer:
Ahogy a 10.0.0.1 nincs debrecenben (egy budapesti ügyfélnek), úgy a bb01.budapesta.rdsnet.ro cím sincs Romániában. Ha ott lenne, nem tudnád 1-2ms alatt elérni. És de, igen: sokkal nagyobb lesz a pinged egy valódi román IP-re. Keress román hosting szolgáltatókat, és pingeld őket. Mutatok egy példád:
Láthatod, hogy hol kezdődik Románia. A mindenféle vizuális traceroute alkalmazások ott tévednek, hogy azért mert egy host névben szerepel a .ro, vagy mert a whois román céget dob egy cím vagy tartomány tulajdonosának, az a cím attól még egyáltalán nem biztos, hogy Romániában van fiizkailag. Például ha az RCS betelepül a BIX-re, akkor az egyik budapesten lévő router láb biztosan román tuajdonú IP lesz, de ettől még nem lesz Romániában. Ezt kellene megérteni.
De tőlem azt hiszel el amit akarsz, csak itt ne terjeszd ezt a butaságot. Többször előjött már ez a téma, minden alkalommal ez lett a konklúzió.
Ha problémád van a szolgáltatással, máshol kell keresni a forrást, az egészen biztos.
[ Módosította: radi8tor ]
-
válasz
Kicsimix
#80750
üzenetére
Szinte biztos voltam benne, hogy valami visual traceroute-os baromság lesz az eredmény (mint korábban megannyi alkalommal), de gondoltam várjuk ki a végét. Ugye a "nem teljesen inkompetens" személynek nem megy az alap fizika, vagy az IP tranzitok működése...
A 2. HOP amit neked a csodás alkalmazásod románnak jelöl, nyilvánvalóan nem lehet romániában, mivel akkor nem érnéd el 1-2ms alatt, az fiizkai képtelenség. Próbálj meg bármilyen ismert román (értsd: tudható módon romániában host-olt) címet pingelni, és látni fogod, hogy a tipikus válaszidő ennél lényegesen nagyobb a legjobb esetben is.
A többi meg a butaság hatvány alakja: honnan a tökből veszi bármilyen alkalmazás is, hogy a 10.0.0.1 (ami egy privát, belső hálózati cím) hol van fizikailag? Teljes nonszensz. Nálam is 10.0.0.1 az első hop, mint ahogy az összes Digi-s előfizetőnél, az a PPPoE szerver gateway címe az OLT-ben.
Tehát megint kiderült, hogy érteni kéne valamihez, mielőtt lejártjuk magunkat. Semmilyen forgalmad nem megy át sem Debrecenen, sem Románián. Ezek a tények.
Mint az 5G, meg az agyrák...
-
válasz
Kicsimix
#80739
üzenetére
Már megint a régi nóta, hogy románián át viszik a forgalmat... Csináltál erről az irgalmatlan butaságról 5 hozzászólást, de egy darab traceroute eredményt nem látok... Az FTTB és az FTTH mögött ugyanaz a tranzit van, kizárt dolog, hogy az egyik jelentősen más irányba menjen, mint a másik (az ugyanis pénzbe kerülne, nem is kevésbe). Spórolnak vele, hogy fölöslegesen utaztatják... "Mint nem teljesen inkompetens személy" <-- csak ezt ne írtad volna
A másik meg, hogy a speedtest geoip alapján igyekszik a legközelebbi szervert bedobni, de ha adott területen több is van, akkor próbálja elosztani közöttük a terhelést, mert attól is mérhetsz szart, hogy az adott szerver, vagy az azt kiszolgáló peering túl van terhelve. Ezért érdemes alapvetően kézzel a szolgáltató hazai szerverén mérni, mert ott nincs peering/tranzit hibalehetőség (a szerver persze lehet túlterhelt).
Szóval hagyjuk ezt a románozást, ha nem tudunk ehhez hihető bizonyítékot is felmutatni (ami korábban sem skerült senkinek).
-
válasz
Livius
#80337
üzenetére
Hogy a papírba pontosan mi került azt nem tudom, de nálunk kijött egy muki a Digi-től, hárman körbejártuk a három lépcsőházat, én elmagyaráztam a palinak hogy mi a használható nyomvonal, nekik ez megfelelt (nyilván én ellenőriztem, hogy ezek a nyomvonalat átjárhatóak-e korrekt módon azzal a kábellel, amit használnak), és ennek megfelelően készült el a kivitelezés. Tekintve, hogy a papírban benne van, hogy a nyomvonalat egyeztetik a közös képviselővel, lehet hogy semmi sem került külön a társasházi nyilatkozatba, de az biztos, hogy egyeztetés volt (mivel részt vettem benne), és a szerint készült el a kivitelezés is. Nálunk nem volt gányolás, de az is igaz, hogy a Digi-nek óriási szerencséje volt azzal, hogy a társasház oldalán volt valaki, aki nem csak az épületek felszállóit ismeri, de tervezett már optikai hálózatot is. A másik amit fontos tudni, hogy a Digi nem ás: tehát FTTH területen (oszlopon vannak) csak úgy hajlandóak betelepülni, ha ezt légkábelezéssel meg lehet oldani. Nálunk ez úgy néz ki, hogy az utcai villanyoszlopórl felmentek a társasház első lépcsőházának a tetejére, és onnan a régi lépcsőházi közös antennarendszer felszállóin dugták le a saját kábeleiket, a lépcsőházak között szintén légkábel van.
-
Mi kikötöttük az írásos engedélyben, hogy csak a már meglévő felszállókat használhatják, és ez így is lett. Persze ezt az is megelőzte, hogy a közös képviselővel végigjártuk az összes helyet, és ellenőrizük, hogy ez az elvárás teljesíthető-e, mert ha a felszállók tökig televannak akkor hiába várod el, hogy belehúzzák
-
-
válasz
TeeJay
#80201
üzenetére
Nem biztos az. Ezek a brutális lassulások (5-10-20megabit) nekem sokkal inkább hajaznak valami L2 problémára a végeken. Például a flow control hiányára, vagy hibás működésére. Nálam az ONT bridge-ben van, és meglepődve tapasztaltam, hogy a flow control le van tiltva benne. Félre ne érts: a flow control sem csodaszer, de ha ez sincs, akkor végképp nincs semmi, ami megakadályozza, hogy az ONT előtt már kezelhetetlenné váljon a dobás, ami ugyanúgy FIFO, mint úgy általában az ethernet. Ha egy LAN szegmenst ilyen módon túlterhelnek, akkor a switch minden fajta válogatás nélkül dobál, amit a TCP ilyen kellemes 5-10megabites sebességgel jutalmaz meg. És simán lehet, hogy a 100-as porton lévő előfizetőket akár a switch belső felépítése miatt jobban érinti Sem ezek a buta switch-ek, sem az otthoni felhasználásra szánt ONT-k nincsenek ilyen jellegű terhelés kezelésére méretezve. Legalább annyi eszük lehetett volna, hogy a gigás csomagok bevezetése előtt kirakjanak valami kisvállalati ONT-t, amiben legalább kulturáltan lehetne lassítani, amikor túlterhelés van.
-
válasz
TeeJay
#80195
üzenetére
Ezek nem kapacitás problémák, hanem amiről már beszéltünk itt párszor: a gagyi L2 switch-ek így kezelik a torlódást: dobálják a kereteket. A "legjobb" a helyzet ott lehet, ahol a 4 portos ONT-n van három gigás előfizetés, és a negyedik portjára még rányomtak egy switch-et. A 3 gigás előfizetőből csak egy nyom egy kövér speedtest-et, ne adj isten masszívan töltöget, és a többi a switch mögött kb. ilyen sebességeket fog látni, meg brutális csomag dobást.
-
válasz
togvau
#80174
üzenetére
Bel-óbudán meg csak Telekom DOCSIS van, fossá torlódva... Szóval átérzem a problémát
TeeJay:
A tanulság az, hogy mielőtt az ember túlságosan nagy ívű kijelentéseket tesz, és megpróbál következtetéseket levonni országos szinten, ahoz nem elég a haveri körben lévő szerelő tapasztalata. Az, hogy neki sok munkája van, amögött lehet az is, hogy a Telekomnak van területileg kevés embere, csak ez a saját perpsektívájából nem látszik. Póznától az erdőt
-
válasz
TeeJay
#80161
üzenetére
Az NMHH 2020Q1-es jelentés szerint xDSL-ből 657.841, kábelnetből 1.293.935, és FTTx-ből 864.772 előfizetés van országosan, de az FTTx-ben benne vannak a LAN-os területek is. Az 5%-kal lehet hogy rossz helyen járt, de a "fél országot bekötik optikával" sem állja meg a helyét.
-
-
válasz
bobalazs
#80114
üzenetére
"Én meg arra gondoltam hogy firmwaret frissíteni nem lehet másképp csak fizikailag, localhoston keresztül. Jól értem?"
Csak a szolgáltató tud firmware-t frissíteni, és az az egész HGW-t frissíti, nincs benne különálló modem és router. Ezt a szolgáltató távolról végzi, szintén a TR-069 kapcsolaton keresztül. Így kerül be az eszközbe a telefonhoz tartozó konfiguráció is, de távolról akár ki tudja ütni az elfelejtett wifi jelszavadat is anélkül, hogy az egész eszközt elreset-elné. A TR-069 egy elképesztően jól testre szabdható megoldás, csak attól függ, hogy a szolgáltató mennyit költött el a fejlesztésre, és a testre szabásra (értsd: mennyire kötötte össze az ÜFSZ által is elérhető felülettel). Természetesen egy szabályos távoli frissítés során a a már beállított adataid nem fognak elveszni.
-
válasz
bobalazs
#80110
üzenetére
Úgy látom kis magyarázatra szorul a dolog.
Az eszközök távfelügyeletét TR-069 protokolon keresztül oldják meg. Ez azt jelengi, hogy a szolgáltatós eszközön olyan firmware van, ami alapból tartalmazza a szolgáltató TR-069 szerverének a címét, és egy alap felhasználói nevet és jelszót, illetve egyéb paramétereket amik ahoz kellenek, hogy akár "internet" nélkül is be tudjon jelentkezni rá a HGW/ONT egy komplett reset után. Ugye a Digi esetében ha reset-elsz, nincs PPPoE user név és jelszó, ergó valami egyéb management kapcsolatra is szükség lesz, különben az eszköz a reset után nem éri majd eé a TR-069 szervert, hogy az adatokat onnan visszatöltse (GPON-nál lehet ez például belső management VLAN).
Természetesen ennek semmi köze nincs a saját magad által eszközölt beállításokhoz (tűzal, port forward, wifi beállítások stb.), azt neked kézzel kell majd reset után visszaállítani. Tehát reset-et nem a szolgáltató nyom a saját végén (ÜFSZ), hanem biztosítja a feltételeket (egyéni firmware, TR-069 szerver, alap konfig ennek az eléréshez) ahhoz, hogy egy előfizető által előídézett reset után az eszköz visszamásszon a hálózatra, és a szolgáltató azt távolról felügyelni tudja, illetve arról hálózati statisztikát tudjon gyűjteni. Tehát a reset-et neked kell nyomni, de azért előtte nem árt legalább a saját PPPoE user neveddel és jelszavaddal tisztába kerülni, mert ha kis számban is, azért volt már olyan, hogy reset után mégsem talált vissza az eszköz TR-069-en keresztül.
-
válasz
Attila 1
#79958
üzenetére
Miért ne tudná? A D3.1 amúgy is kevésbé érzékeny erre, nem véletlenül azt szokták feltolni 6-800MHz közé. A koax egy árnyékolt hálózat. Ha kellően "tömör", akkor semmiféle külső zavartatásnak nem lenne szabad bejutnia. Persze nem vagyok naiv, az ezeréves szar, nem lezárt hálózatok szedik össze a zajt most is, ezt a szerelők megfelelő képzésével, az elvégzett munka ellenőrzésével, és tervszerű karbantartással lehet elkerülni (értsd: költeni kell rá). A deep fiber szintén segít, mert a koax szegmensek egyre rövidebbek, kevesebb és jobb minőségűek az erősítők stb. Nade ez pénzbe kerül.
-
válasz
viktorhu
#79941
üzenetére
A Digi-t ez egyre kevésbé érinti, mert kopnak ki a klasszikus KTV területek. Egyébként már a 800-as ripacskodásnál sem értettem, hogy mit gondoltak: majd ha nyavajognak, az állam nem fogja ezt a sávrészt értékesíteni? De ha már itt tartunk: a rádió amatőrök zavarják a visszirányt, az összes kiadott URH rádió engedély, DAB kísérleti adás, LTE450 (kormányzati háló) stb. meg zavarja az előre irányt. Tehát ezen az alapon mindenki szűnjön meg létezni 1GHz alatt, mert a drága KTV szolgáltatók nem akarnak karbantartani? Az egész érvelés teljesen nonszensz.
-
válasz
Attila 1
#79936
üzenetére
Dehogy veszítik el. Csak most majd költeniük kell arra, amibe beleszartak 20 évig. A tömörtelen koax hálózatot végre karban kell tartani, a lezárókat felrakni, és aktívan monitorozni kell a hálózatot, hogy hol van zajosodás. Ezt eddig is csinálni kellett volna, csak nem volt rá külső kényszer. Ezt a rizsát lemnyomták már a 800-as sávnál is, de ott még az jött ki olcsóbbra, hogy egyszerűen feladták a 790MHz feletti részt. Most ezt már nem lehet majd eljátszani, és el lehet kezdeni majd a munkát...
-
válasz
TeeJay
#79894
üzenetére
Nálunk már volt egy harmadikán. De mondom: az érdekes az hogy hajnali kettőkor 300/50 többször is több szerverre, és egy sima pppoe újracsatlakozás után hasít. Ez nem terhelési probléma lesz, sokkal inkább tűnik úgy, hogy valamilyen elv alapján korlátoznak. A lassú és a nem lassú IP más tartományban volt, de ezt még nem nevezném konklúzív bizonyítéknak
-
Ma ismét észrevettem a korábban már jelentkező 300/50-re lassuló kapcsolatot, miután a PPPoE kapcsolatot a szolgáltató bontotta. Több mérést is csináltam, következetesen ennyi volt az eredmény. Ezek után csak annyit csináltam, hogy újraindítottam a PPPoE kapcsolatot, és utána ment minden normálisan. AZ összehaosnlító mérések most készültek, tehát biztosan nem csúcsidei terhelés áll a háttérben.
-
válasz
4Grider
#79812
üzenetére
Egyetértek. A másik amit kerülni kell, azok az újfajta "könnyen szerelhető" dugók, ahol a vezetéket át lehet tolni a csatlakozón, és a krimpelő szerszám vágja egyformára az ereket. Annyi fals hibát, rövidzárat még életemben nem láttam, mint amit ezekkel a dugókkal szerelt hálózat produkálni tud... Cserébe a csatlakozó és a szerszám is drágább...
-
válasz
TeeJay
#79772
üzenetére
Köszi a linket, mostmár legalább tudom hogy 3-án éjszaka miért volt kiesés. Mondjuk kitalálni nem volt nehéz, de az tök jó, hogy következetesek. Emlékszem a telekmnál az utolsó időben minden héten volt 1-2 alkalommal CMTS reset éjszaka, de tájékoztatni azt egyetlen alkalommal sem sikerült.
Korábban volt téma a Digi peering kapcsolatai: kis trace route-olás segítségével könnyű volt kideríteni, hogy van direk peering-jük a Google felé is, tehát a közhiedelemmel ellentétben nem a Bix-en kapcsolódnak össze.
-
válasz
Patice
#79620
üzenetére
Ha LAN kábelt kap és nincs saját routere, akkor nem lehet címütközés. Ha van routere akkor lehet, de általában a VPN-t olyan privát címtartományba rakják, amit jellemzően nem használnak otthon (10.x.x.x vagy 172.16.x.x). Próbáljon meg pingelni egy olyan IP címet, ami csak VPN-en érhető el. Ha az megy, a VPN faszán működik.
-
Rosszul érted. A GPON technológia sokkal inkább képes a torlódásokkal megbírkózni, mint a mezei switch-ek, amiket a Digi FTTB-nél használ. Az, hogy vannak szerencsés kivételek ahol - akár az előfizetők korösszetétele, akár a felhasználás jellege miatt - nem tapasztalható lassulás, az nem azt jelenti, hogy az FTTB jobban bírja a terhelést mint az FTTH/GPON. Pont fordítva: ha azokon a helyeken ahol már behúzták FTTB területen az optikát, már beüzemelték volna, jelentős mennyiségű ügyfél nem tapasztalna csomag dobást, csak elfogadható mértékű lassulást az esti csúcsban. Abból sem érdemes messzemenő következtetést levonni , hogy van itt 5-10 ember akinek valóban szar FTTH-n is. Országos szinten ebből következtetést levonni hogy szar a Digi elég hajmeresztő fantazmagória. Úgy tűnik az emberek gyorsan elfelejtették, hogy milyen szolgáltatásért és mennyit fizettek a Digi előtt. Én jól emlékszem a Telekom DSL-re meg a Telekom DOCSIS-ra, és nem sírom vissza egyiket sem.
-
Erre van a szolgáltató összehasonlítós topik. Ennek semmi keresnivalója itt, főleg a sok szar képpel. A moderátor nyugodtan törölhetné, mint ahogy az utóbbi héten tonna számra érkező irreleváns (értsd: problémával nem rendelkező) speedtest mérést tartalmazó posztokat is.
-
válasz
TeeJay
#79452
üzenetére
Ha az uplink lassul, az 110% hogy torrent és/vagy szerver üzemeltetés (nem otthoni NAS, hanem hosting pénzért). Nincs semmilyen más forgalom ami tartósan megkajálná az uplinket, főleg úgy, hogy közben a torlódásra sokkal érzékenyebb DL meg jól működik.
Az meg, hogy esetleg 5-10 évvel ezelőtt hogy építkeztek nem jelenti azt, hogy most is így van. Ha igaz lenne a 32 lépcsőház egy porton elmélet, most aztán végképp fossá torlódná magát a DL, de a mérésediből nem ez látszik. Nagy terhelés alatt FTTB-n inkább a buta lépcsőházi switch-ek fogják megadni magukat és dobálni a csomagokat.
-
válasz
TeeJay
#79442
üzenetére
Biztos lehetsz benne, hogy nagy OLT-ket használnak, mivel az fajlagosan a legolcsóbb, főleg a kerületet kiszolgáló OLT-nél. Átviteltechnikából meg minden OLT uplink port ezer éve 10gigás, tehát a legrosszabb esetben is van 4x10giga egy OLT-ben, de a nagyobb 16U-s darabokban talán alap a 2x4 port, ezt most meg kéne nézni. CWDM mux-ot nagyon olcsó és gyors bővíteni, de nem is nagyon éri meg mondjuk fél kapacitással kiépíteni, mert pár száz eurót tudsz megspórolni vele.
-
válasz
TeeJay
#79438
üzenetére
"de az OLT meg csak pár gigabites gerincen lóg"
A kérdésedre a válasz rajta van a képen, amit beraktál a Hua OLT-ről: Nx10gigán lógnak az OLT-k, jellemzően CWDM-en több hullámhosszon. Ha megfigyeled, nem véletlen, hogy 8-10 csatornás CWDM rendszerek vannak mostmár olcsón, és pont 8-10 port van a jellemző OLT kiépítésekben. Tekintve, hogy az OLT lokációk nagyon sok előfizető (néhány esetben több kerület) forgalmát szolgálják ki, ezért nehéz elképzelni, hogy ezen spórolna a digi, hogy csak 2-3 hullmáhosszat épít ki. A CWDM mux ott van, a port kártyát kifizette, maximum a két SFP+ modul árát spórolja meg.
És tekintve, hogy a gerinc (helyesen felhordó hálózat vagy access, ugye az OLT előtti rész sehogy nem nevezhető gerincnek) mindig szimmetrikus, míg a GPON nem az, ezért nem túl valószínű, hogy felhordó hálózati limitáció okozza ezt a jelenséget, ha lefelé állításod szerint megvan a sebesség.
-
válasz
MadMancs
#79425
üzenetére
Kiválaszthatod a 4K-t, csak 25%-kal kisebb bitrátával fogod megkapni.
Livius:
Nem mondom, hogy nem láttam még ilyet. Viszont ha az a kérdés, hogy összedől a hálózat, vagy kifizetjük az expertet (ugye rövid távon nem lehet kapacitást bővíteni), akkor hirtelen a válsághelyzetben előkerül a lóvé rá.
-
#79423
dchard
veterán
Dragon3000
#79422
válasz
Dragon3000
#79422
üzenetére
Persze ez világos, de abba nem halsz bele ha 2-3 hétig "csak" 500megabitet kapsz, ellenben ezzel terhelni most az ügyfélszolgálatot... Praktikus volna, ha olyanok telefonálnánka, akiknek valóban komoly gondjuk van. Ez egy speciális helyzet, sokkal toleránsabbnak kéne lenni.
Az is érdekes, hogy a streaming szolgáltatók "önkorlátoztak", de a teljesen haszontalan forgalommal a hálózatot rángató speedtest nem mondta azt, hogy nem kéne két percenként mérni, esetleg ezt meg is tiltja, vagy csak óránként egy mérést engedélyez stb.
-
#79419
dchard
veterán
Intruder2k5
#79418
válasz
Intruder2k5
#79418
üzenetére
A 8-10megabit optikán valószínűleg nem alulméretezés, sokkal inkább valami beállítási hiba lehet OLT oldalon, esetleg tényleg olyan szerencsétlenül jött ki a lépés, hogy éppen most van valódi műszaki hiba. Azt volna érdemes tisztázni - és akár az összefoglalóba is beleírni - hogy mi lehet az a szint, aminél lehet azt mondani, hogy a jelenlegi túlterhelés az oka, és mi az ahol már érdemes bejelenteni. Személy szerint én 1-200meabitet elfogadhatónak tartok optikán, de a 8-10megait az gyanúsan műszaki hiba, biztosan bejelenteném (miután kizártam a saját hálózatomat, és eszközeimet).
-
válasz
TeeJay
#79405
üzenetére
Erre senki nem fog bővíteni, arra viszont jó ez az egész, hogy kikísérletezzék az optimális QoS beállításokat, amivel értelmes lassulás mellett de csomagdobás vagy a késleltetés látványos megugrása nélkül még ki lehet szolgálni az igényeket.
Az mondjuk érdekelne, hogy FTTB-n ahol egy sima ONT-t megy bridge-ben egy komplett lépcsőház egy buta switch mögött, ott vajon hogy oldják meg az értelmes QoS-t? Az itteni FTTB-s pocsék szar (10-20megabit alatti) mérésekből arra következtetek, hogy sehogy, simán dobálják a csomagokat azt kész.
-
#79283
dchard
veterán
dragon1993
#79281
válasz
dragon1993
#79281
üzenetére
Ha nem ment volna át, lelövöm a poént: mindkét cégnek sokkal több peering-je van a valóságban, mint amit a peeringdb listáz. Erre próbáltunk meg viktorhu-val utlani. A magyar telekomnak szerinted tényleg kettő darab privát peering-je van? De a digi-nél is van legalább egy olyan peering, amiről tudjuk hogy létezik és nincs listázva.
-
#79278
dchard
veterán
dragon1993
#79275
válasz
dragon1993
#79275
üzenetére
Már majdnem elhittem, aztán megnéztem, hogy az oldal szerint a telekomnak is két darab peering-je van, amiből világosan kiderül, hogy az oldalon látható adatok teljesen megbízhatatlanok.
-
Kérdés: más is tapasztalta, hogy a Task Manager hálózat fülén a valósággal semmilyen kapcsolatot nem mutató sávszélesség használatok jönnek ki? Esetleg megoldást is talált már erre valaki? Nálam 300megabites feltöltésre 5-600megabitnyi sávszélességet mutat, ami teljes képtelenség. A driver friss.
-
válasz
4Grider
#79256
üzenetére
Nincs Digi kft szerver, mivel képtelenek voltak ennyi hónap alatt megoldani a HTTPS-t, kirúgták őket a hivatalos listából. Helyette a linkelt oldalon is az egyéb budapesti szervereket dobálja fel. Csak CLI-ből érhető a valóban digi-s szerver, ha tudod az ID-t. Sehogy máshogy.
-
válasz
adika4444
#78954
üzenetére
Engem nem is feltétlenül a 4-500megabites letöltés aggaszt, hanem a következetesen száz megabitet teljesítő feltöltés. Az sem azért, mert olyan rettenetesen töltök felfelé, hanem inkább azért, mert az ilyen mértékben napszaktól független lassulás valamiféle hibát indikál.
Aktív témák
Olvasd el az összefoglalót!
Társtopikok:
● DIGI kábel TV
● DIGI Mobil
● DIGI műholdas TV
● DIGI vezetékes telefon
Router kérdésekkel ezekbe a topikokba fáradjatok!
● Milyen routert?
● Router gondok
- Mindenféle könyves (és olvasós) Off topic
- Google Pixel 10a – évismétlés
- Hegesztés topic
- Manjaro Linux
- Kész rémálom lesz Linuxot használni jövőre az USA egyes államaiban
- ASUS RT-AC68U
- Kerékpárosok, bringások ide!
- Napelem
- Kertészet, mezőgazdaság topik
- Samsung Galaxy Buds3 Pro - szárat eresztettek a babok
- További aktív témák...
- Hario MINI MILL SLIM PLUS tekerőt keresek, mert elveszett
- Raktáron levő AM4 garanciás alaplapok!!!
- ÚJ Apple Airpods Pro 3 - www.stylebolt.hu - 1 Év Apple garancia - 27 százalékos Áfá-s száma !!!!
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max
- iPhone 14 Pro Max 256GB 100% (1év Garancia)- ÚJ EREDETI AKKUMULÁTOR - AKCIÓ
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest