-
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
Beniii06
#95124
üzenetére
Nem sikerült megérteni az alap problémát: nincs a piacon olyan GPON SFP modul, ami tudna nagyobb sebességet, mint 1gbit/s az SFP oldalon. SFP+ modulból van XGS-PON, de horror áron, és nem is nagyon hozzáférhető úgy mint a Mikrotik vagy a Ubi elérhető GPON moduljai.
Azt sem sikerült megérteni, hogy a GPON nem ADSL, minden ONT-hez saját OMCI profilt kell gyártani, hogy működjön. És ebből a szempontból a GPON SFP modul egy komplett ONT, mivel a GMAC magán a modulon van implementálva. A Digi-nek az volna a kényelmes, ha semmilyen végberendezést nem kéne adnia, mert az pénzbe kerül (lásd: FTTB), viszont minden előfizetőnek saját OMCI profilt gyártani, azt nem fogja senki meglépni.
A megoldás az lehetne, hogy felvesznek 1 vagy 2 népszerű SFP GPON modult, amit lehet tőlük venni, és azt támogatják.
-
Elhiheted, hogy jópárat megnéztem. A probléma az, hogy sima PON-on nem nagyon van igény gyorsabb csomagra mint 1gigabit, így senki nem akar egy valag plusz pénzért SFP+ képes GPON modult gyártani. Persze vehetsz XGS-PON modult ami már SFP+, és az visszafelé kompatibilis a GPON-nal is, csak hát ha a sima B+ modul 60 EUR, akkor az XGS-PON képes mibe kerül?
Tehát létezik erre műszaki megoldás, de ebben az esetben kevésbé tűnik reaálisnak. Nekem is van 1-2 darab XGS-PON modulom ami SFP+ (vagy XFP), de nagyon vigyázok rá, mert elképesztően drága. -
-
Mutass nekem egy olyan sima GPON modult, ami SFP+ interfésszel rendelkezik
Én eddig csak 10GPON-ból láttam ilyet. Persze nem lehetetlen, hogy a Digis úriember rendelt egy 10GPON modult, ami visszafelé kompatibilis, csak azért hogy legyen 2gigabitje, csak hát ez elég drága buli. Meg ugye SFP+ port kell a router oldalán is. Ennél sokkal valószínűbb, hogy vett egy Mikrotik vagy Ubi SFP GPON modult, ahol a limit 1/1gigabit. -
válasz
Ejelhar
#94855
üzenetére
Feltételezve, hogy nincs műszaki hiba, FTTH-n sokkkal jobb szolgáltatás minőséget lehet nyújtani, mint FTTB-n. Kevesebb aktív eszköz, kevesebb hop, tisztességesen működő QoS és a többi. Hosszan lehetne sorolni az alapvető műszaki különbségeket az FTTH (vagy pontosabban a GPON) előnyére. Ki merem jelenteni, hogy ha bárki rosszabb minőséget tapasztal az FTTH átkötés után, az kizárólag valamilyen lokális probléma lehet (szarul heggesztett szál, ONT hiba, port hiba).
-
válasz
Varszegig
#94741
üzenetére
Annyit tennék hozzá, hogy ha érkeresztmetszet-különbség van (különböző érkeresztmetszetű kábelek vegyítése), ott a kis mértékű impedancia változás miatt változik a frekvencia menet. Ez abból a szempontból érdekes, hogy a kolléga szeretné kimaxolni a 100 métert, én ebben az esetben hajlanék a végig a jobb kábellel elvre, még ha kicsit macerásabb vagy adott esetben drágább is.
-
válasz
Celtis
#94491
üzenetére
És mi van akkor, ha egy 96-os, vagy 192-es PON törzskábelt fújt el a szél? Távolról sem biztos, hogy az OLT előtt van a hiba (ennyit a gyűrűről). Gyanús is, hogy ha ennyi ideig tart, akkor megy a "cérnázás" ezerrel, és nem 1-2 szálat kell helyrerakni. Az OLT-t előtt jellemzően egyébként Nx10giga van, tehát egy szál, vagy interfész hibát valószínűleg kibír (hacsak nem WDM-ben megy az összes hullamhossz), de ha kihúzzák a kábelt a földből, akkor ennyi volt.
-
válasz
adika4444
#94465
üzenetére
Mondok jobbat: Huawei CPE-kben (ami kültéri és beltéri egységből állt) találtunk olyan hibát, hogy a két eszköz közötti belső kommunikációt úgy oldották meg, hogy az egyik 1.1.1.1 a másik 1.1.1.2 címet kapott a zseniális Huás mérnököktől, ami azt eredményezte, hogy az eszköz mögül nem lehetett elérni a CF DNS szerverét.
-
válasz
MadMancs
#94406
üzenetére
Egy darabig valóban az volt a helyzet, hogy adott OLT típus alá azonos gyártó ONT-it rakták, de ennek semmi köze nem volt a szoftverhez. Egyszerűen a profilozás és a logisztika miatt egyszerűbb volt így. Az összes ONT-nek működnie kell az összes OLT-vel, ha a megfelelő OMCI profil el van készítve az adott típushoz. Ez konfiguráció kérdése.
-
válasz
MadMancs
#94143
üzenetére
Lópikulát nem kell regisztrálni már ezer éve. Egyszerűen arról van szó, hogy a modem egy darab DHCP lease-t szolgál ki, ami jellemzően a bekapcsolás utáni első cím lesz. Ilyenkor a modemben létrejön egy "összerendelés" (binding) a kliens eszköz MAC címe és a kiosztott IP cím között. Példa: bedugod a PC-t a modembe, mert ki akarod próbálni. Minden fasza, majd a PC-t kihúzod, rádugod a routeredet (vagy egy másik PC-t) és azt látod, hogy nem kap címet. Ilyenkor vagy várni kell huzamosabb ideig (DHCP lease lejártáig ami elég sok idő is lehet), vagy fogod magad és újraindítod először a modemet, aztán a klienst. Ennyi az egész.
-
-
válasz
TeeJay
#93999
üzenetére
Nem a drágasága a kérdés: az, hogy minden nagyobb DC-t jól elérjenek mondjuk EU-ban, ahhoz is számos peering kell. Nem annyi a történet, hogy most éppen koppan az egyik, akkor toljunk bele még pár gigabitet. A nagy európai inkumbensek (főleg a DT és a Voda) komoly előnyben vannak, mivel gyakorlatilag van saját kapcsolatuk szinte minden lényeges kicserélővel, vagy akár privát peering-jük is a méretüknél fogva.
Nekem nincsenek nagy elvárásaim, nyilván ha USA-ba, Dél-amerikába vagy a távolkeletre kéne jó kapcsolat, már rég nem lennék a Diginél. De az, hogy mostmár EU irányban is egyre többet vacakol, az kezdi betenni a kaput.
-
#93996
dchard
veterán
Dragon3000
#93995
válasz
Dragon3000
#93995
üzenetére
Biztosan digi-t érintő gond van, minden lokális vagy direkt peering mögött lévő helyre jó a sebesség. Holland host-ról stabil 80megabit. És persze ha amsterdam-i SP szerverekkel tesztelek, akkor kijön a 3-400megabit, de amikor valami konkrét kontent kéne, akkor jönnek ezek a fospermet eredmények.
-
A nemzetközi irány mostmár egyre bosszantóbban lassú. Persze nem AWS, Drive, MS és társai, hanem bármi akinek nincs direkt peeringje. A Nokia EU-s szerveréről most pont 2megabittel tudok letölteni, és nem a túloldalon van a szűk keresztmetszet... Mostmár egyre bosszantóbb a dolog. És persze hullámzik, de 10mega fölé soha nem megy.
-
válasz
TeeJay
#93877
üzenetére
Nem véletlenül írtam azt amit.
Egyébként ez ugyanúgy egy szélső érték mint amit 4Grider írt: attól, hogy "nincs gond vele", meg hogy "működik a gigabit" simán lehet szerencse is, vagy észre sem veszi, hogy néha el-eltűnnek csomagok. A teszt az én szempontomból azt jelenti, hogy rádugom a műszert, ami a komplett frekvencia menetetét, áthallását, összes elektromos jellemzőjét. megméri, és a mért értékeket összeveti a szabványban szereplővel, majd kiírja, hogy annak megfelel-e vagy sem. Az, hogy valakinek szerencséje van és 120 méter hosszú kábellel is működik, vagy 5 toldással (főleg az olcsó műanyagokkal) egy másik történet. A problémát én abban látom, hogy még soha egyetlen szerelőnél sem láttam ilyen műszert, ami nem led villogtatás, hanem konkrét mérés. -
válasz
4Grider
#93874
üzenetére
"A toldók használata nem szabványos"
Tudok neked mutatni minősített, időjárás álló CAT6 toldót, amihez adnak cert-et is. Mi több, ha közé dugom az analizátort (nem a led villogtatós bohózatot), minden létező mérhető elektromos jellemzője is bőven a szabványban lefektetett értékeken belül van. Persze ez nem a 3 eurós műanyag vacak lesz. Bár ebben az esetben elég egyértelmű, hogy a toldóknak nincs köze a problémához.
-
válasz
ballazol
#93629
üzenetére
Egymagos régi MIPS alapú QCA proci van benne (már ha nem a ralink verzióból kaptál, azonos név alatt több HW verzió van nagyon eltárő képességekkel). Ennyit is csak azért tud, mert van benne CTF (a Qualcomm sw offload megfelelője), tisztán erőből ennyit sem tudna kinyomni. Ha wifin keresztül használod, ennyit sem fog tudni, mivel jellemzően a Wifi IO load jóval nagyobb terhet ró a processzorra.
-
Ebből arra következtetek, hogy nem nagyon érted a hálózati stack működését. Hiába "jön le valami a gépedig", ha annak nincs erőforrása a megérkező adatot feldolgozni, mert például a 20 darab reklámot rendereli éppen. A sebességmérés nem annyiból áll, hogy kiesik a kábel végéből a bit, azt jónapot.
-
válasz
MadMancs
#93023
üzenetére
Próbáld így:
C:\Speedtest_cli>speedtest.exe -s 31717
Speedtest by Ookla
Server: Digi Kft - Budapest (id = 31717)
ISP: Digi TV
Latency: 0.87 ms (0.20 ms jitter)
Download: 933.01 Mbps (data used: 469.9 MB)
Upload: 325.45 Mbps (data used: 147.6 MB)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/53b6cdaf-8dc5-43c6-9c47-3d2abe94001bÍgy mindig a Digi szerverén fog mérni. A webes sosem mér ennyit, és nem a vas gyenge.
-
"Ez meddig jönne be egyébként"
Végig. Az oszlopon lévő kötődoboz után nem toldozgatnak, egy kábeltípus jön végig. Az, hogy milyet kapsz, az nyilván függ a helyzettől. Ha nálad végig csőben fog menni, lehet hogy nem a legdúrvább acélmerevítős kábelt fogod kapni.
Én a villanyon túl legalább két üres csövet beraknék (behúzószállal együtt), arra tessék vigyázni, hogy ezeknek fel kell érnie viszonylag magasra, mivel az oszlop oldalán ez jelenti a mechanikai védelmet is. A két üres csőnek legalább az optikáig, a villanyosnak meg a szolgáltató által meghatározott magasságig.
-
" ha jól értelmezem, akkor ha a járda alatt is be lenne húzva a cső azon az 1 méteres szakaszon, akkor lejönne fentről a Digi kábel a villanyoszlop tövében"
Ez kizárólag akkor lehetséges, ha külön cső jön le az oszlopról. Az ELMŰ által (a ház villamos bekötésére) használt csőben nem lehet semmi más, csak a villany, ráadásul ez a cső az ELMŰ tulajdona még abban az esetben is, ha te építetted ki. Erre érdemes nagyon odafigyelni, mivel számos jogvitáról tudok ami ilyen esetekből származott. Ha van külön cső, akkor ez nem probléma. VIszont ha nincs, akkor megoldás lehet az amit írtam: egy kellően magas fém rúd a kerítés vonalában, ami elég magas a bekötéshez (főleg, ha az út túloldaláról húzzák az utca fölött).
-
Ez egy összetett kérdés: a Digi magától nem fog elásni kábelt, az biztos. Ha te mondjuk a ház építésénél kialakítottál a földben erre alkalmas csövet behúzószállal, akkor minden további nélkül behúzzák abba, de vedd figyelembe, hogy ebben az esetben a cső végénél (kerítés környéke) ki kell alakítanod egy kellően magas pontot, hogy az utca/járda fölött át tudjanak jutni. Valószínűleg van ehhez előírt minimum magasság is.
-
#92320
dchard
veterán
MasterMark
#92316
válasz
MasterMark
#92316
üzenetére
Arról már nem is szólva, hogy hiába van NAT mögött, ha van hozzá haosnlóan NAT mögött lévő peer, azzal ugye aktív csatlakozás jön létre, tehát a Digi NAT userek másik Digi NAT usertől aktív módban tudnak letölteni, csak külső hálózatok felé lesznek passzívak. Ezért is mutat az utorrent zöld jelzést ebben az esetben.
-
válasz
Lewzke
#92086
üzenetére
Nem kell egy kényelmi problémát műszaki problémának álcázni, és akkor nem lesz személyeskedés
"Megoldható lenne a szolgáltatónak?"
Nem oldható meg egyszerűen. Ez az újabb butaság, hogy a Diginek nem érdeke meg ott bukik meg, hogy a Digi az egyetlen szolgáltató, akinél nem kötelező szolgáltatói STB-t használni, meg azért bérleti díjat fizetni. Mielőtt véleményt formálsz, tájékozódj, és akkor kevesebb ilyen kellemetlen pillanat adódik.
-
válasz
Lewzke
#92081
üzenetére
"A nem sztenderdizált optikai szolgáltatás eléggé vicc"
Ha valaki nem ért hozzá, de butaságokat beszél, az is vicces. A GPON a világ vezető FTTH "sztenderdje", a Digi hálózata ennek teljesen megfelel. Neked kényelmi problémáid vannak, azt nem biztos, hogy egy fapados szolgáltató tudja a legjobban kielégíteni.
"ha be is szerzek valami más GPON-t az működni fog-e a digivel?"
Nem, mint ahogy más szolgáltatóval sem. Marad a bridge.
-
-
-
válasz
Masato
#91773
üzenetére
Amikor én speedtest-elek a Digi budapesti szerverére, a forrás címe a csomagoknak egyáltalán nem ez. Hanem a 78.131.0.106. És tekintve, hogy az Ookla a 8080 és az 5060-as portokat használja a szerver oldalon, könnyen ellnőrizhető, hogy valóban ezen a címen figyel a kiszolgáló. Ha nem vagyok indiszkrét, honnan van ez a speedtest1.digi.hu cím?
-
válasz
ToM2oo4
#91718
üzenetére
Két megjegyezés:
1. Ethernet rétegen (L2) nincs újraküldés, az magasabb protokol rétegek feladata (L4 vagy fölötte). FCS hiba esetén dobás van.
2. Mivel az auto-nego a link felépülése során működik csak, nem pedig folyamatosan, aktív link státusz ellenőrzés pedig nincs az ethernet szabványban, ezért simán széthullhat a kommunikáció menet közben úgy, hogy akár a gigabites linksebesség is megmarad, csak éppen alig vagy egyáltalán nem megy át semmi. Röhejes, de így van. Nem véletlen, hogy utólag kellett számos ilyen megoldást belegányolni a szabványba, de ezek SOHO eszközöben nincsenek benne sajnos.
-
válasz
radi8tor
#91617
üzenetére
Érdekes a "too many sessions" üzenet. Ugye ezt a peer (tehát ebben az esetben a PPPoE kiszolgáló) küldi. Ez vagy túlterhelésnél fordul elő (sok száz vagy ezer végpont próbál egyszerre újracsatlakozni egy nagyobb volumenű szakadás után), de jelentheti azt is, hogy az előző kapcsolatodat még nem zárta le a szerver és úgy veszi, mintha ez egy második csatlakozási kísérlet lenne ugyanarról a végpontról. Meg kéne nézni, hogy ez a jelzés melyik esetre vonatkozik...
-
#91565
dchard
veterán
MasterMark
#91561
válasz
MasterMark
#91561
üzenetére
Na ezt nem tudtam. De aki szeret siránkozni, az sosem használna ilyen funkciót, hiszen a lényeg veszne el.
-
#90413
dchard
veterán
ElektrikusDE
#90409
válasz
ElektrikusDE
#90409
üzenetére
és Akosman:
ezekre csak Mucsit tudok idézni: ezt a trágya gány melót... Egyik szarabb mint a másik. Ha ez jellemző (különösen ha ezért még bekötési díjat is szednek), akkor nyomnám is fel a fogyasztóvédelemnél őket. Elképesztő. És sajnos az utóbbi időben volt itt a topikban minden féle gánya szerelésről fotó, tehát érzésre nem egyedi eseteket látunk.
-
válasz
TeeJay
#90217
üzenetére
Szerintem itt többféle hiba lesz, amit az emberek hajlamosak összemosni. Az én meglátásom az, hogy van egy FTTB-t érintő probléma, és egy általános core vagy peering probléma.
Az FTTB-t évek óta nem bővítik és a tervszerű karbantartása sem valósul meg, mondván hogy jön az FTTH, ami egyes helyeken éveket csúszott. A SOHO switchek kezdenek döglődni egyre nagyobb számban + eleve rájött erre a CoVID okozta extra terhelés, miközben a forgalom managelésre ezek a switchek képtelenek, tehát ha torlódás van, dobálnak. Ezek együttese azt a benyomást kelti, hogy általánosságban szar az egész FTTB. És az előfizetők csekély százaléka érti meg, hogy FTTH-n majd merőben más lesz.
És ott van még az "általános" hiba, ez is úgy tűnik több tényezős: például aki nem Digi DNS-t használ, sokkal kevesebbszer, és kevésbé érzékeli ezt a problémát. Nálam például sosem volt olyan durva lassulás, vagy teljes szolgáltatáskiesés a decemberi 1-2 hetet leszámítva, de akkor is inkább lassulás volt, meg 1-2 oldal elérhetetlen volt, de melózni tudtam, holland VPN is hasított. Messze nem volt olyan dráma, mint itt többeknél. Tehát központi hiba is lehet több féle van: a DNS minden szolgáltatónál gyenge pont, és sokan érzékelik ha nem vagy akadozva megy. Emellett volt kapacitás probléma is valahol, de azt mi sosem tudjuk meg. A DIGI speedtest servere jellemzően jó eredményt adott, ezért a hálózaton belüli súlyos hibát vagy torlódást ki lehet zárni. Marad a CR és/vagy a peering, esetleg ezek együttese + routing vagy load balance probléma. Nézegetve a BIX lábat, a bővítés óta a szumma forgalom tovább nőtt, és a hibák is akkor szaporodtak meg, ez némiképp a CR irányába tereli a figyelmet, amit messze nem olyan könnyű cserélni. Ez nem egy SOHO router 20 ropiért a hülye azért nemvagyokban
Azt is el tudom képzelni, hogy év végén a beszerzése sem egyszerű egy ilyen cuccnak. Ráadásul nem csak megvenni kell: ha például nagyobb kategóriára bővítettek, akkor újra kell építeni az architektúrát is, ami lehet nem ment zökkenőmentesen, egy ilyen kaliberű eszközt ki kell tapasztalni, nincs hozzá user manual. Például egyetlen tűzfal szabály ha rossz helyre kerül a táblában, jelentősen javulhat vagy romolhat a teljesítmény.Sokat lehetne még erről értekezni, de itt most lezárom, mert ez már túlmutat a Digin
-
válasz
TeeJay
#90207
üzenetére
Normálisan beállított QoS és shaping mellett nem akkora probléma ez: ha van kapacitás akkor ki lehet hajtani, ha pedig nincs akkor lassabb lesz. Ennyi. Tekintve hogy a shapinget már az ONT-ben el lehet végezni uplink irányban (az OLT ütemezési döntése alapján természetesen), így elég jól lehet szabályozni torlódás esetén. Más kérdés, hogy ebben az esetben TRM-et, országos bevezetésnél pedig core-t is bővíteni kell, kihazsnálástól függően ez a drága dolog, nem a PON rész, amit csak át kell konfigurálni. És tekintve, hogy érzésre core problémák vannak mostanában (vagy peering, sosem tudjuk meg), így meg tudodm érteni az óvatosságot is.
-
#90159
dchard
veterán
Intruder2k5
#90149
válasz
Intruder2k5
#90149
üzenetére
Lassan be lehetne rakni az összefoglalóba
-
-
-
#89344
dchard
veterán
Dragon3000
#89341
válasz
Dragon3000
#89341
üzenetére
Mint láttad, én is azt írtam: általánosságban a két mag volt a jellemző. Persze a magszámtól függetlenül is az egy magra vetített IPC is jelentősen elmaradt bármitől az elmúlt 3-4 évből. Az architekturális különbségekről már nem is beszélve.
CoF:
Akkor ugyanarról beszélünk
-
-
#89180
dchard
veterán
Dragon3000
#89175
válasz
Dragon3000
#89175
üzenetére
Nincs az az ÁSZF pont, ami ebből a szarból kimosdatja őket. Ez teljesen vállalhatatlan. Aki egy F csatit nem tud felnyomni a koax végére, az inkább kapáljon.
-
válasz
4Grider
#89151
üzenetére
A második idézett mondat elég egyértelműen leírja, hogy ha például én kapok egy STB-t is (mivel kábeltv-re előfizettem és jár a szolgáltatás részeként az egy darab STB), akkor a kábeltv szolgáltatás vételére alkalmas végberendezés (mely a szolgáltató tulajdonában van) az STB, és nem pedig az ONT, ezért már most meg is dőlt, hogy az ONT az átadási pont. És ha az STB az átaádsi pont, akkor az előtte lévő koax hálózatért is felel az ONT és az STB között.
Arról nem beszélve, hogy ha a szolgáltató embere pénzért kiépíti a hálózatot, azért ugyanúgy felel, hiszen a munkájáért jótállással tartozik. Ha azért a gányolásért pénzt vett fel, akkor garanciális javításra kötelezhető, és majd ha bizonyítást nyert, hogy az ügyfél gányolta össze (bizonyítási kényszer a szerelőn, csinált fotót amivel tudja igazolni, hogy hogy adta át a munkát?), akkor lehet azt mondani, hogy nincs garanciális javítás.
Érzésem szerint az egész probléma abból fakad, hogy a szerelők alig tudnak valamit kiszámlázni, így nem nagyon éri meg az ügyfélnél sok idő alatt igényes munkát végezni, ezért inkább a címekre mennek. Az ügyfél pedig nem mondja azt, hogy csinálja meg rendesen több pénzért, de ingyér elvárná, hogy a budiba is kikábelezzék neki a hálózatot. Ennek az ellentmondásnak a feloldása a gyorsan gányolok, és nem kérek érte pénzt, így felelősségre sem lehet vonni hozzáállás.
-
#89147
dchard
veterán
Dragon3000
#89143
válasz
Dragon3000
#89143
üzenetére
Szerintem legalább egy végpontig ki kell építenie, az ÁSZF-ben foglalt feltételekkel (valamennyi talán benne van ingyen, utána fizetni kell stb.). Ez a trógerolás csak akkor elfogadható, ha tájékoztatja a usert, hogy a meglévő kábelezés felhasználásával meg tudja csinálni, de 10-ed annyi lesz csak a max sebesség (100Mbit).
Az már csak hab a tortán, hogy ez a közösen visszük egy UTP-ben az ethernetet meg az analóg telefont, nem felel meg semmiféle kötési normának sem. A telefon vonalon a csengetéskor 100-105Volt váltakozó feszültség is lehet, ezt összeereszteni a +-2.5 Voltos ethernettel, főleg ezekkel az ócska árnyéklatlan kábelekkel... Ez az első pillanattól kezdve rossz gyakorlat volt, most meg kezd a nyakukra égni.
-
válasz
TeeJay
#88790
üzenetére
Nem a Digi hülyesége. A PON hálózatok power limitesek. Minden egyes végpont amin nincs előfizető rontja a hatékonyságot, mivel az optikai teljesítmény függetlenül attól, hogy a végponton van-e ügyfél, elosztásra kerül. Tehát hacsak nincs monopólium, én 44 lakásra egy 32-es osztót tervezek, és ha abból van 26 előfizető az messze nem olyan jó, mintha lenne 32 és azt a plusz 1-2 előfizetőt meg elviszi más, aki építheti ki a felesleges osztások miatt a hálózatát rosszabb megtérüléssel
Tehát összefoglalva: ha egy PON porton a power budget 32 vagy 64 előfizetőt tesz lehetővé, az a jó, ha 32 vagy 64 előfizető van rajta. Nem neked, hanem a szolgáltatónak. Ha ügyes a hálózati topológia (van elég tartalék szál), akkor lehet játszani: például ha egy területen jobbak a szintek az előzetesen tervezettnél, akkor lehet további osztást betenni, vagy egy kevéssé kihasznált portot visszabutítani mondjuk 64-ről 32-re és egy 1:2-es osztóval tovább vinni a ki nem használt "teljesítményt" máshol. -
2. kerületben elvileg 01:00-től indul a karbantartás, de már döglődik egy csomó irány
Szerintem reszelik már a témát. 8.8.8.8 nem válaszol, 1.1.1.1 még igen. -
válasz
CirrMee
#88509
üzenetére
Ez jó kérdés, de azt biztosan állíthatom, hogy több különböző gyártó termékével is ez volt a helyzet. Többnyire azért nem csúcs i7-es masinákat kell elképzelni. Ügyfélpanasz kivizsgálás miatt volt fontos, hogy találjunk stabil megoldást giga/giga kapcsolatok megbízható mérésére. A megoldás saját speedtest szerver (a maghálózaton belül), és saját magam által felkészített laptopok voltak Speedtest CLI-vel. Minden más esetben bizonytalan mérés, vagy egyenesen vacak eredmények jöttek ki. A forgalomelemzést végző tűzfal/antivírus is képes elképesztő módon visszavenni a sebességet. A legtöbb esetben ügyfél oldalon is a gyenge PC (hw vagy sw oldalon is jelentkezhet ez a "gyengeség") a fő hibaforrás. Személyesen 24 PON végpontot néztem át, de ebből egyszer sem hálózati hiba okozta a lassulást. Ez utóbbi sokat elárul.
-
válasz
CirrMee
#88505
üzenetére
Én annyit tudok neked mondani, hogy 2600x-szel FF szépen ki tudja mérni a maxiumot is, ugyanez igaz a CLI-re is, de az is igaz, hogy következetesen mindig a Digi szerverét választom. Esetleg próbáld meg így, ha még nem tetted volna.
A CLI appról annyit, hogy egy Rasberry Pi 4-en a hivatalos speedtest CLI app is simán kimér mindkét irányban gigabitet, tehát erőforrás problémát CLI oldalon biztos nehéz lenne találni.
Olyat viszont már nem egy laptopnál láttam, hogy ha nincs bedugva, és/vagy nincs kiválasztva a maximális teljesítményű profil (volt olyan hogy a bedugás sem volt elég, a profilt is be kellett állítani), a mérés simán megállt 600meganit körül, és bőven nem volt a proci egyetlen magja sem 100% közelében. Bedugás és profil váltás után ugyanez a laptop kimérte a gigabitet.
Ezek a saját tapasztalataim.
-
válasz
MadMancs
#88383
üzenetére
"Ennek a fiberhome cuccnak tv kimenetén se kép se hang, illetve TV led se világít."
Naná, hogy nem. Ezt távolról tudják állítani. Nem csak ki/bekapcsolni, de tudnak bizonyos keretek között gain-t is állítani.
" kb 1 órát hegeszgetett/szerelt csak a lépcsőházi dobozban."
Ez nálunk is így volt, de szűrő az nincs a dobozban, csak az osztó (amire megfelel a leírásod: "2mm vastag és kb 6cm hosszú sötétszürke merev valami"), meg a bekötött szálak.
-
Maximum FTTB-n. GPON-nál a QoS-nak OMCI-n kell beállítva lennie, különben az OLT nem tudja megfelelően priorizálni a forgalmat. Az OLT egy alapvetően L2 eszköz, ahol a PON Queue-k és a VLAN-ok összerendeléséből, illetve a hozzájkuk beállított sebesség profilokból áll össze maga a modell, ehhez képest a PPPoE egy magasabb szint.
-
válasz
4Grider
#87792
üzenetére
Érdemes figyelembe venni, hogy a port upgrade nem feltétlenül jelenti azt, hogy nincs valahol routing limitáció. Simán előfordulhat, hogy a port upgrade után a megnövekedett forgalmat a router már nem tudja kiszolgálni, és ezzel küzdenek. De lehet más limitáció is átviteltechnikán, amit a port bővítés hozott elő.
-
válasz
TeeJay
#87730
üzenetére
Az AX lényege, hogy az OFDM moduláció elvégezhető frekvencia szelektíven is (ezt hibásan OFDMA-nak hívják, amihez persze semmi köze). Az AC például OFDM modulációt használt, de csak időosztásban lehetett több klienst kiszolgálni, és a kis sebességű forgalomnál is ez volt a megoldás.
-
#87628
dchard
veterán
MasterMark
#87627
válasz
MasterMark
#87627
üzenetére
Olyan értelemben nem lenne mindegy, hogy egy tisztességes lista tükrében könnyebb lenne potenciálisan nem radarral terhelt csatornát választani. A DFS-t pedig sajnos számos eszközben ki lehet kapcsolni, tehát az üzemeltetőknek is érdeke volna, ha könnyebb lenne elkerülni ezeket a frekiket.
-
válasz
pinnacle
#87623
üzenetére
Na akkor nézzünk valami hitelesebb forrást: [link]
"budapesti radarnál ~5625 MHz, vidéki radaroknál ~5610 MHz"
Ebben persze Ferihegy, az Időkép és esetleg egyéb nem ismert de radar üzemeltetési engedélyel rendelkező szereplők használata nincs is benne.
Mivel a 40-50 eurós wifi routerek nem spektrumanalizátorok, ezért a radar deteketálás lehet hibás is (fals deteketálás vert jelből például). Nálam 120-as csatornán például nincs radar detektálás, de egy fél hegy kitajarja dél-pestet, ahol a radarok vannak.
-
-
Nálam 25ms Hollandia. Talán sosem volt még ilyen jó
VPN-en látok egy-egy dobott csomagot nagy ritkán, de ha ugyanezt a host-ot nem VPN-en pingelem, akkor jó, tehát ez az egy-egy csomag sem Digis probléma. -
válasz
Sisco2
#87423
üzenetére
Toronto nekem 250/300mega (ez teljesen jó), Sydney 300-as válaszidővel 70/70.
Az üzleti csomag fiy IP-vel nem fog segíteni, de átpakolni sem fogják, csak mert neked rossz. Mérjél speedtest.net-en az említett két városra. Ha 100mega felett vagy (Sydney esetében ez a 70/70 már jó), akkor a túloldali szerver van szar helyen hostingolva, esetleg ha még VPN is van, akkor a céges VPN szerver nemzetközi iránya a szar, vagy a feltöltésre használt protokol nem többszálú vagy rosszul tűri a 100ms+ válaszidőt. Akárhogy is: ezt a Digi nem fogja neked megoldani.
-
válasz
viktorhu
#87326
üzenetére
"Lehet, hogy a 128-asnál is nagyobb osztást alkalmaz?"
Ez valószínűtlen. A sima GPON nem tud 1:128-nál többet, nem hiszem hogy belemennek valamelyik vendor semmivel nem kompatibilis bővített OMCI protokol implementációjába. A másik meg, hogy a legtöbb helyen power budget sem lenne még az 1:128-ra sem, nemhogy felette.
-
válasz
TeeJay
#87151
üzenetére
Hogy mit hogyan kéne csinálni tökéletesre, meg mi a gazdasági realitás, az két külön dolog. Sokkal jellemzőbb, hogy redundáns (!) kapacitásból soha nem áll rendelkezésre annyi, amennyi a csúcs terhelést le tudja kezelni. Nyilván ennek is van méretgazdaságossága: nem mindegy, hogy két CR-ből szarik be egy, vagy 5-ből, esetleg 10-ből. A másik, hogy a komolyabb CR-ek port és linecard szinten is redundánsak, tehát az hogy "beszarik" egy komplett CR, szinte elképzelhetetlen. Tehát összességében sokkal jellemzőbb, hogy tandemben működnek a CR-ek, ha úgy tetszik a redundancia másodlagos, inkább a terhelés elosztás a fő funkció.
-
Szerintem félre érted a dolgot. A hülyeség az, hogy a beszélgetés folyam amire válaszoltál, annak az elején a kérdező összekötötte a sávszélesség és a szolgáltatói névszerver használatát, ami valóban hülyeség, vagy nevezzük tájékozatlanságnak.
Egyébként a legtöbb tipikus operációs rendszeren 300-600 másodperc a DNS cache egyes bejegyzéseinek az élettartama, utána mindenképpen új lekérdezés történik, de vannak esetek, amikor ennél sűrűbben is. Ergó mindegy, hogy naponta milyen oldalakat nézel, de az is mindegy, hogy óránként mit nézel
Legalább is DNS cache szempontból. -
válasz
TeeJay
#87114
üzenetére
Nekem sem volt eddig semmi gondom, pedig napi több órát skype-olok nyugat-eu-val. Ha csak egy kicsit is bizonytalan lenne a kapcsolat, az gyorsan feltűnne. Persze előfordulhat, hogy pont ez a peering mindig atom stabil, a többi meg vacakol, csak hát ennek kevés az esélye. Az is igaz, hogy sosem használtam a Digis névszervereket.
-
válasz
TeeJay
#87089
üzenetére
Arról nem beszélve, hogy ha valóban core router gond van, az ugyanúgy értinti az FTTB ügyfeleket is, ahogyan az látszik is. Engem is lecsaptak 160mega uplink-re, de legalább stabil a szolgáltatás. Nálunk TV-vel telefonnal nem volt gond.
Az is érdekes, hogy a face-n előkerültek a "már hetek, hónapok óta szar" ügyfelek. Gondolom ők "hetek, hónapok óta" be is jelentették ezt, hiszen ha nekik valóban hosszú idő óta szar, annak semmi köze a jelenlegi hibához.
-
#86989
dchard
veterán
MasterMark
#86855
válasz
MasterMark
#86855
üzenetére
Szerintem az MSS clamping-et minden router csinálja PPPoE-n, ellenkező esetben eddig is szart mértek volna, különösen uplink-ben.
A DNS szerveres ötleted tűnik jónak, nálam évek óta Cloudflare és google van az első és második helyen, és az elmúlt napokban teljes kiesésem nem volt, csak néhány weblapnál lehtett érzékelni (inkább külföld felé), hogy igen lassú, illetve YT is lassan bufferel.
Megnézve a két DNS szervert (CF és google) az előbbi keveseb HOP és nem használ külső peeringet, utóbbi kettővel több HOP és peering-en éri el. Ez utóbbi azért is érdekes, mert mind a kettő elérhető direktben a BIX-en keresztül is. Szóval ezért is érdemes minimum ezt a kettőt használni.
-
válasz
TeeJay
#86786
üzenetére
Ha tippelnem kéne azt mondanám, hogy vagy a 100gigás port upgrade, vagy a hozzá kapcsolódó bővítések/átterelések környékén lesz a hiba. Az hogy ennyi ideig nem tudják elhárítani azt jelzi, hogy esetleg hw limit lesz valahol (például a bővített kapacitást nem tudja valamelyik router kinyomni).
Ezt némiképp megerősíti, hogy a saját speedtest szerverük (ami hálózaton belül van, bőven a BIX előtt), az frankón működik, ennek ellenére oldal betöltések, YT nézés az elég vacak (főleg ha bele tekerek vagy gyorsítva nézném).
-
válasz
qnadam
#86642
üzenetére
Majdnem megkérdeztem tőle, hogy mennyi tapasztalata van mérőszerver üzemeltetéssel, de aztán rájöttem, hogy van jobb dolgom is
Használtam már kismillió féle engine-t szerver oldalon, de az a helyzet, hogy a körülményessége ellenére az Ookla terméke tűnik a leginkább megbízhatónak, különösen a gigás sebességek tekintetében. Nálunk alkalmas ONT-vel saját szerverrel ki tudom mérni a 2.3gigát is (az ONT-n 2.5gigás ethernet port van), bármi más volt a szerver oldalon, teljesen következetlen eredmények jöttek ki. -
#86614
dchard
veterán
Lajosnagy17
#86612
válasz
Lajosnagy17
#86612
üzenetére
A kisebb hálózatok felvásárlása évek óta zajlik. 5 évvel ezelőtt még 200-nál is több kistérségi hálózat üzemelt, 2019 végére 70-nél is kevesebb maradt. A bekebelezés pedig tovább zajlik. Őszintén szólva fájó kimondani, de az esetek nagy részében az ügyfelek jobban járnak ezzel. Amennyi lerohadt méregdrága ilyen hálózatot láttam már az országban, nem tudom jó érzéssel azt mondani, hogy kár értük.
-
válasz
viktorhu
#85820
üzenetére
Hogy mi volt 2006-ban, arra nem emlékszem. Kb. 10 éve foglalkozom ezzel, azóta biztosan nem volt Románián keresztül routolt forgalom (legalább is nem nyugatra). Pedig 3 havonta bedobja valaki
Emlékezzél csak vissza az elmúlt egy évre. Volt itt minden a PPPoE szerver belső hálózati IP címét Debrecenbe rakó visual traceroute-tól addig hogy még a belföldi forgalmat is Románián át routolja a Digi. -
válasz
adika4444
#85811
üzenetére
A legjobb valóban Romániában hostolt IP-re 19ms a ping, az átlag 20-25ms. Ehhez képest te 10-11ms-ot mérsz a BIX-re. Semmi bizonyíték nincs mostmár sokadszorra, erre a nettó hülyeségre, hogy bármilyen hazai vagy nyugat-európai forgalom Románián keresztül menne.
Ami sokkal valószínűbb, hogy esetleg a székesfehérvári kábelátvágás nem csak regonális de tranzit útvonalat is érinthetett, ezért most más irányba, esetleg tartalék tranziton mennek a csomagok (nem Románián át természetesen). Ez magyarázza a megnőtt válaszidőt, és a csomag dobást is, mivel előfordul, hogy a tartalék útvonal nem képes a teljes forgalmat kiszolgálni. Az is előfordulhat, hogy a tartalék útvonal IPv6 routing-ja nem 100%-os. Ezek közül bárminek van esélye a román teóriával szemben. El kéne már felejteni ezt. Ahányszor eddig felmerült, annyiszor derült ki, hogy tévedés.
-
válasz
Borisz76
#85768
üzenetére
"Nincs dedikált ki és bemenet."
Pontosan. Az összes port egyforma, és mivel az összes internetes forgalom kétirányú, ezért a ki és bemenet fogalma nem értelmezhető. Minden port ki és bemenet egyszerre. Amit mpo jelezni akart, hogy mindegy hogy melyik portot hova dugja: egy port megy a HGW felé, a többi a kliens eszközök felé. Konfigurálni nem kell semmit.
mpo:
Amit linkeltél, az a feladatra teljesen megfelel, de nincs kimenete meg bemenete
Egyenértékű portjai vannak, mint az összes switch-nek. -
válasz
TeeJay
#84213
üzenetére
Titkosítás mellett nincs. DPI kell hozzá, ami ilyen forgalom mellett a UPC-nek sem érte meg annó, ki is vezették. Kizárt hogy egy budget szolgáltató ilyesmibe ruházna. Inkább azt tudom elképzelni, hogy ebben nem csak konzumer forgalom van, lehet adatcenterek között másolnak valamit.
-
Ugyan leszoktunk róla, de most érdemes mégis egy pillantást vetni a BIX statkóra:
Péntek óta átlagban 40%-kal nőtt a forgalom a BIX irányon. Ez azért nem kevés. Nyilván peering variálás lehet a háttérben, érdekes lenne megtudni, hogy mi változott. Interkonnektre érzékenyek most nézegethetik, hátha látnak valamit.
-
#84128
dchard
veterán
MasterMark
#84127
válasz
MasterMark
#84127
üzenetére
Nem fogalmazza meg pontosan, de a példa szempontjából ez mindegy is.
-
válasz
adika4444
#84125
üzenetére
"Szolgáltatói oldalról van az álláspont amit írtam"
Ez városi legenda, nem több. Az ÁSZF tiltja a szerver üzemeltetést, és kész. Ugyanúgy tiltja kábelnetnél is (DHCP), mint PPPoE-n. Sehol nem mondja a szolgáltató, hogy azért bontja 168 óránként (korábban 24 óránként), hogy te ne tudj szervert üzemeltetni (amiben ez egyébként nem akadályoz meg).
"De akkor DHCP-nél miért tudják megoldani, hogy a lejárati idő felénél megújul az IP, tehát közel soha nem szakad?"
Mert a DHCP protokol úgy működik, hogy a lease time lejártakor a kliens újrakéri ugyanazt a címet, amit már kiosztottak neki, és ha erre nyugtával válaszol a DHCP szerver, akkor megtarthatod a korábbi címedet ugyancsak a lease time erejéig. A legtöbb komolyabb DHCP szerverben van rá lehetőség, hogy ilyen esetben is kényszerítsék az új címet, mégsem bajlódik ezzel egy nagyobb szolgáltató sem. Itt is látszik, hogy a szerver üzemeltetős érvelés bukó. PPPoE-nél nincs lehetőség csak a címet megújítani, ez nem része az IPCP (Internet Protocol Control Protocol)-nek. Itt az időkeret a PPP kapcsolatrészhez tartozik LCP-n keresztül, mely magának a PPP kapcsolatnak az állapotáért felel. A PPPoE ugye több alapprotokol együtesséből áll össze (LCP és IPCP), előbbi a link állapotáért felel, utóbbi az IP kommunikációhoz szükséges feladatokat végzi (IP cím, átjáró, DNS szerverek alapvetően), tehát a dinamikus címzést nem DHCP szerver csinálja, és nem DHCP a protokol sem. Ez a hátránya a PPPoE-nek: a link kontrol és az IP kontrol nem különül el.
AKit érdekel, megnézheti protokol szinten: [link] wireshark kell a fájl megnyitásához. Látható, hogy a PPPoE részben nincs semmi a címzésel kapcsolatban, az az IPCP részben van, amihez viszont nem tartozik időzítő.
-
válasz
adika4444
#84116
üzenetére
Dehogy ez a magyarázat...
Az alapvető logika diktálja azt, hogy cím ne lehessen valamiféle időkorlát nélkül kiosztva sehova sem úgy, hogy a kiszolgálónak ne legyen módja a hibás működés detektálására, és ilyen módon a cím felszabadítására. Ez a távközlési protokolok egyik alap tervezési paradigmájához vezet vissza aminek a lényege, hogy a szóbanforgó protokol (illetve a hozzá tartozó állapotgép) deadlock-free legyen, vagyis ne fordulhasson elő olyan állapot, amiből nincs kiút. Ezért is van minden protokol tele időzítőkkel és számlálókkal, amivel ellenőrizhető a helyes működés. Teljesen mindegy hogy PPPoE, vagy DHCP (mobilnetnél PDCP).
Tehát létezik erre műszaki megoldás, de ebben az esetben kevésbé tűnik reaálisnak. Nekem is van 1-2 darab XGS-PON modulom ami SFP+ (vagy XFP), de nagyon vigyázok rá, mert elképesztően drága. 
A PON felé néző oldala természetesen tud 2.4Gbit-et, hiszen ez a szabvány. Viszont az SFP elektromos interfész (ami a router felé néz) csak 1gigabitet tud.
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
- Akciókamerák
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Anime filmek és sorozatok
- exHWSW - Értünk mindenhez IS
- Milyen légkondit a lakásba?
- Világrekordot ünnepel az ASRock
- Ilyen olcsó sem volt még egy Apple notebook
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Unigine Superposition Benchmark
- További aktív témák...
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Gamer/streamer mikrofon, állvány és USB HUB kitűnő árakon!
- Bomba ár! Panasonic CF-20-2 Tab+Laptop: i5-7G I 8GB I 256SSD I 10,1" WUXGA Touch I Cam I W11 I Gar
- iKing.hu Apple iPhone 15 Pro Max 256GB használt Black Titanium 91% akku 6 hónap garancia
- ÁRGARANCIA!Épített KomPhone i5 14400F 32/64GB RAM RX 9060 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest