-
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
adika4444
#101461
üzenetére
Amit írsz, simán megtörténhet. Például simán lehet olyan CF (vagy más host), ami Románián keresztül bizonyos napszakokban gyorsabban érhető el. Vagy éppen romániában van hostolva, de az is megtörténhet, hogy valamelyik útvonalon hiba vagy karbantartás miatt csak a román útvonal marad relatíve használható.
Nade ezt ne keverjük már azzal az általános állítással, hogy a forgalom Románián át megy, ami úgy nem igaz, ahogy van. Arról nem beszélve, hogy nincs az az isten, hogy egy Budapest-Bécs-Frankfurt útvonal drágább és rosszabb minőségű legyen, mint ugyanez Románián át. Az már csak hab a tortán, hogy Románia EU-s tranzitjának 99%-a Magyarországon keresztül megy. Hová is menne? Ukrajnába, Moldovába, esetleg Szerbiába? Ugyan... A nagy nemzetközi tranzit szolgáltatók mint a Liberty, a Voda a Telekom, a Telia is Magyarországon keresztül éri el a nyugatot ha Románia felől nézem. Szóval sehogy nem jön ki a matek. Kivételek lehetnek - több szempontból is - de nem többek annál: kivételek.
-
válasz
4Grider
#101439
üzenetére
Ez komoly? Még mindig nem sikerült ezt a Bukarest baromságot abba hagyni? Hányszor kell még elmondani, hogy nem megy a nemzetközi forgalom Bukaresten keresztül? Az hogy van néhány random hülye aki betéved ide a lófütyi telkó tudásával és előadja ezt a kreténséget egy téves visual traceroute alapján egy dolog. De te elég sokszor láthattad a levezetést azzal kapcsolatban, hogy ennek semmi valóság alapja nincs.
-
válasz
Lokids
#101336
üzenetére
Nálam a pár nappal ezelőtti éjszakai leállás óta drasztikusan javult a CF DNS (korábbi 10+ms helyett 1-2ms), a Gugli DNS marad a korábbi 1-2ms:
C:\Users\Administrator>ping 8.8.8.8
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=2ms TTL=118
Reply from 8.8.8.8: bytes=32 time=1ms TTL=118
Reply from 8.8.8.8: bytes=32 time=2ms TTL=118
Reply from 8.8.8.8: bytes=32 time=2ms TTL=118
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms
C:\Users\Administrator>ping 1.1.1.1
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=2ms TTL=58
Reply from 1.1.1.1: bytes=32 time=1ms TTL=58
Reply from 1.1.1.1: bytes=32 time=1ms TTL=58
Reply from 1.1.1.1: bytes=32 time=1ms TTL=58
Ping statistics for 1.1.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms -
-
válasz
Plazmacucci
#101245
üzenetére
A csúcsidei torlódás szerinted szándékos?
-
válasz
Plazmacucci
#101242
üzenetére
Hát persze. Még véletlenül sem mondjuk csúcsidei torlódás...
-
válasz
Dragon3000
#101226
üzenetére
Főleg annak tudatában vicces a dolog, hogy tudjuk: a gyorsabb csomagokat alapvetően a nagyobb feltöltés adja el. Az majdnem tökmindegy az átlag embernek, hogy 250-500 vagy 1000megabit a letöltés, de az már nem mindegy, hogy két párhuzamos Teams hívástól megmakkan a kapcsolat. Arról már nem is beszélve, hogy ezek nem elenyésző vidéki kiragadott példák: több budapesti kerületben konkurencia nélkül bőven van még hely, ahol a Telekom ennyit bír magából kiizadni, ennyiért...
-
-
válasz
proradeon
#101150
üzenetére
Hagyjad, 25 éves IT múlttal nem lehet vitatkozni. Csak azért nem írtam valami sokkal csúnyábbat tegnap éjszaka, mert még hatott a Tubi

Hogy a fenébe van az, hogy nekem 20 év telkó múlttal eszembe nem jut győzködni itt bárkit is, hogy milyen csomagra fizessen elő, meg hogy mit lehet kihasználni meg mit nem....
-
válasz
tutitibi
#101129
üzenetére
"Minek az SSD", "minek az NVME SSD", "minek a 100megás net", "minek az 500-as net", "mindek a 16giga ram", és még lehetne sorolni az analóg idiótaságokat, amiket a hozzád hasonlók beböfögnek 10 éve mindenhova. Kurvára tele van már ezzel az ember töke. Nem kell neked? Semmi gond. Nem fizetsz elő rá, nem veszed meg. Köszi, puszi. Ezt az agit-prop tevékenységet pedig be lehetne fejezni egyszer s mindenkorra.
-
válasz
Zolle74
#101029
üzenetére
Ha már megszólított Teejay, akkor válaszolok.
Az OLT-kben jellemzően C+ optika van, tehát a 31-es (valójába -31dBm-es) vételi szint még a specifikáción belül van, bár közel a határhoz (-32dBm). AKárhogy is: ha router módban jó, bridge-ben pedig nem, akkor ennek semmi köze a jelszintekhez, mert akkor egyformán szar lenne mindkét esetben. (a B+ optika vételi szintje -28dBm, de ilyet OLT oldalon már elég régóta nem használnak, de a szerelő ellenőrizheti ha akarja).
Ha a Digi oldalán van ez a probléma (nem vagyok róla meggyőzve), akkor a bridge profillal lehet gond az OLT oldalán, de akkor minden bridge módban lévő ügyfélnek szar lenne az adott OLT-n, nem csak neked.
TeeJay:
Ha szar az uplink, az simán okozhat problémákat a letöltési sebességben is. Persze nehezen lehet szar az uplink,, ha megvan a 300mega felfelé minden időszakban, bridge és router módban is

-
válasz
TeeJay
#100980
üzenetére
Ha jól látom a probléma az, hogy brdige-ben szar a sebesség router módban meg nem.
Az előfizetett sebességet lefelé az OLT ütemezője "korlátozza", felfelé pedig a modemben lévő QoS profil. De ez nem "letöltődik" a modembe, hanem egész egyszerűen a modem ONT része szerves egységet képez az OLT-vel, ezt az OMCI nevű protokollon keresztül vezérli az OLT. Tehát az ONT alárendelt viszonyban van az OLT-hez képest.
Én elsőre arra tippelnék, hogy valamelyik kliens eszköz nem jól kezeli a PPPoE-t és ez adja a különbséget a router és bridge mód között. De ha már tényleg több különböző és kellően potens laptoppal/PC-vel ki lett próbálva, akkor van egy kis esély arra, hogy valóban az OLT profillal lesz a hiba. De ezt a mezei ÜFSZ nem fogja tudni kideríteni, csak a mérnök (akinek van közvetlen OLT hozzáférése és kézzel le tudja ellenőrizni az aktuális profilt).
MOD: ha jól látom a fenti hozzászólásban akkor ez megtörtént. Esetleg meg lehetne próbálni a kliens eszközök (ami PPPoE tárcsázna) kikapcsolni a flow control-t, számos esetben okozott már problémát.
MOndjuk, hogy a "szerelő laptopja sem kezeli jól a PPPoE kapcsolatot", az elég vicces...
-
-
-
válasz
TeeJay
#100555
üzenetére
A probléma az, hogy még PC-n csak beállítja az ember kézzel (bár nem kényelmes), de telefonon nem fogok fix IP-t állítgatni (ami mellett tudsz névszervert beütni) csak azért, mert a Digi letiltotta még ezt is a saját routerében, miközben ott figyel a menüben. Rém irritáló.
-
válasz
TeeJay
#100542
üzenetére
Napi érdekesség: havernál Huawei ONT van, nem heavy user, elég nekik. Múltkor azt csinálta, hogy nem volt névfeloldás, de nem a Digi névszerverei szartak be, hanem a routerben lévő DNS forwarder. Újraindítás után megjavult. Kíváncsi lennék, hogy az itt megjelenő DNS panaszok hány százaléka lehet hasonló eredetű... Természetesen az ONT-ben ott van a saját névszerver beállításának a lehetősége, de ki van szürkítve, nehogy az ember át tudja állítani...
-
válasz
viktorhu
#100435
üzenetére
Ez világos, de a koncesszió nem tiltotta meg más szolgáltatók megjelenését, hanem a korábbi állami telkó vagyon felosztásáról szólt. Az más kérdés, hogy finoman fogalmazva is ellehetetlenítette más szolgáltatók megjelenését, de nem úgy hogy megtiltotta, hanem egyszerűen gazdasági öngyilkosság lett volna belépni azokkal a feltételekkel...
-
válasz
so_ha
#100430
üzenetére
"Telekom alkuja sem derült ki a rendszerváltás után az aktuális kormánnyal (illetve az utána jövők is valamiért szemet hunytak fölötte), mégpedig hogy kizárólagos joggal építi ki az országos telefonos hálózatot (amin később ADSL-t is szolgáltatott)"
A Telekom vagy pontosabban a Matáv piaci előnye nem abból származott, hogy tilos volt hálózatot építeni, ilyen soha nem történt, nem tudm honnan veszed ezt. A probléma az volt, hogy a Matáv megörökölte a korábbi állami telefonhálózat-vagyon nagyobbik részét, ami ráadásul olyan koraszkban épült, ahol mindenből hiány volt, így mindenki szemet hunyt a tróger kivitelezés mellett. A Posta által épített hálózatra sosem vonatkzott az az állami burokrácia, engedélyeztetés stb. ami bármelyik mai piaci szerelőre igen. Az így megszerzett hálózat mellett pedig nem érte meg "piaci alapon" senkinek sem saját hálózatot építeni, de ez a telefon rendszertechnika jellegéből fakadóan soha nem érte meg más nyugati országokban sem. Tehát ilyen konteós butaságokat hogy mi volt tilos meg mi nem, nem kell terjeszteni. A Digi sem véletlenül csak ott versenyez, ahol nem kell alépítményt kialakítania, mert vagy nincs rá szükség (ELMŰ oszlopsor), vagy a korábbi kivásárlás miatt szert tett rá (belváros). Óbudán nem véletlenül nem jött 10 év alatt egy méterrel sem közelebb, pedig az utca végén vannak...
-
válasz
ElektrikusDE
#100378
üzenetére
"Van vagy nincs torrent korlátozás?"
Ezzel az ONT-tal nincs, egyelőre?
Hát az ONT-n biztosan nincs, és nem is lesz "torrent" korlátozás...
-
válasz
Nemo1
#100018
üzenetére
Ez nagyszerű, csak a GPON modul nem ethernet. Mi fogja vezérelni? Nem az a kérdés, hogy fiizkailag bele tudja-e dugni. Itt vannak sokan tévedésben a Digi Zyxel ONT-jével is. Azért mert ki tudja belőle húzni a modult, még nem jelenti azt, hogy más eszközben működni is fog. Azt kell érteni, hogy az esetek nagy részében a modul csak a fizikai réteget csinája, az úgynevezett MAC (közeghozzáférés-vezérlés) már az SFP+ port túloldalán van, ami ugye ethernet. Namost ha te beledugsz egy GPON modult egy olyan portba, ami mögött ethernet vezérlő van, az működni sehogy sem fog.
Vannak olyan GPON modulok, amik a komplett L1+L2 részt a modulon tartalmazzák, de ebben az esetben is kell valamiféle vezérlés a port túloldala felé. Ha nagy szerencsénk lesz akkor a Zyxel-ben ilyen modul lesz, de ezt sem fogja tudni átdugni egy Asus routerbe.
-
-
-
válasz
TeeJay
#99943
üzenetére
Így van, ez egy komoly upgrade, nem megy gombnyomásra. Attól is függ, hogy az OLT-k esetében kell-e kártyát cserélni, esetleg a egész OLT nem XGSPON képes, akkor mellé kell rakni egy új XGSPON képes berendezést. Ha nem combo portokkal csinálják akkor meg a WDM diplexereket kell beépíteni, ez például biztosan éjszakai munka, mert kieséssel jár. A kártya és port modul csere szntén.
-
válasz
TeeJay
#99940
üzenetére
"de hogy kerül mellé az XGSPON hullámhossza"
Két lehetőség van.
1. Combo portokkal, ebben az esetben az OLT-ben lévő XFP modul képes mindkét hullámhosszat kiadni. Ez tűnik a valószínűbb lehetőségnek, bár sok régebbi OLT kártya nem tud egyszerre mindkettőt kezelni.
2. Diplexerek segítségével meg lehet oldani, hogy a GPON és az XGSPON hullámhosszai különböző helyről (értsd: különböző port, kártya vagy akár OLT) egy szálra kerüljenek. Extrém esetben két teljesen külön álló OLT képes kiszolgálni a két technológiát, amit aztán egy szálra illesztenek.
-
válasz
TeeJay
#99938
üzenetére
"Ja átgondoltam"
Dehogy gondoltad át. A PON lényege az, hogy a végpontok számához képest töredék szál megy az OLT-hez. Lépcsőházanként egy splitter, ugyanazon jön majd az XGSPON is mint a GPON. Tehát ha te egyedüliként előfizetsz, akkor az összes többi porton is ott fog figyelni az XGSPON hullámhossza is a GPON-é mellett. Mert hogyan mésképpen lehetne? Nem lesz külön splitter, meg külön szál XGSPON-ra...
-
-
-
MasterMark, TeeJay:
A QNAP 301w routerre készül az OWRT, lesz benne HW NAT és offload is. De ami érdekes, hogy van rajta 2x10Gbit. A 10giga Aquantia PHY-vel készül. Ha venni akarnék 10gigás routert, akkor ezt venném az tuti...
-
válasz
headhunter
#99626
üzenetére
Népszerű "tudomány" című rovatunkat látták

-
válasz
TeeJay
#99611
üzenetére
"Sagemcom 2,5gbit ONT-ben 4 magos Broadcom Arm Cortex 53 proci van"
Mint mindenben mostanában. Az IPQ807x-ben is négy magos A53 van. Nem ez a kérdés. Hanem az, hogy az offload engine mennyire adekvált. A QCA NSS magja például nem csak sima NAT meg PPPoE offload-ot tud, de bizonyos keretek között tud például shapinget is (SQM). Ezeket a sebességeket nem a 4 általános ARM mag fogja csinálni, hanem az offload engine. Ezért sem az az érdekes, hogy hány mag van benne. A memória és az offload képességek a döntőek.
De ha már mindenképpen látatlanban áradozol a 10G ONT-ről, tudunk egyáltalán róla bármit is? Milyen platform van benne, mennyi RAM?
-
-
-
válasz
ElektrikusDE
#99489
üzenetére
30000-ért használtan szerintem sok, de egy korrekt darab ettől függetlenül. BF miatt ezeket az újabb routereket különösen érdemes jól megválasztott helyre rakni a lakásban/házban.
-
válasz
woodworm
#99486
üzenetére
Na várjál, most akkor mire gondolsz pontosan? A gigabit a kompromisszumos, vagy az OWRT úgy általában? Nyilván feltételezem, hogy aki OWRT-t rak fel, az legalább az alapokkal tisztában van, ellenkező esetben a gyári szoftvert tudom ajánlani. Eszembe nincs az átlag józsikára rátukmálni az OWRT-t, csak azt hittem a teljesítményre írtad, hogy kompromisszumos.
ElektrikusDE: nekem Xiaomi AX6-om van, de mostmár lehet hogy inkább AX3600-at vennék. Uugyanaz a platform, de az AX3600-ban picit jobb a wifi frontend. Vezetéken mind a kettő tök egyforma. OWRT egyelőre béta, de abszolút használható.
-
-
válasz
gabro0
#99400
üzenetére
Egészen biztos, hogy ha lesz is ilyen megoldás, maximum vállalati ügyfeleknek fognak ilyet adni. Az is biztos, hogy jó ideig az ONT-ken sem lesz egynél több 10gigás port.
Ha nagy szerencsénk lesz, akkor a PON modult ki lehet majd húzni az ONT-ből, és bele lehet majd rakni Ubi vagy Mikrotik cuccba. De ehhez nagy szerencse kell.
-
válasz
MasterMark
#99315
üzenetére
Hát hallod, képtelen vagyok találni egy komplett leírást, ami az összefoglalóban van pedig elég hiányos és régi, LAN interfész és DHCP beállításokkal egyáltalán nem foglalkozik. Ilyen hülyének 15 éve éreztem magam utoljára.
-
válasz
MasterMark
#99309
üzenetére
Értem. Tehát V6-on az összes LAN cím WAN cím is, ergó nincs NAT, ergó mindent tűzfalazni kell. Ami vicces lesz a dinamikus prefixek miatt, ha jól értem. A videót mindjárt megnézem.
-
válasz
MasterMark
#99303
üzenetére
Pusztán platform fejlesztés miatt érdekessé vált nekem is az IPv6, de rémlik hogy mintha említettél volna valami delegációs problémát a Digi oldalán IPv6-on, amitől valami spéci beállításra van szükség. OWRT alatt már a PPPoE-n van IPv6 cím, tudok is pingelni V6 címeket a routerből, de a LAN rész kompletten hiányzik. Nekem az sem lenne baj, ha a V6 is NAT-olva lenne, az egyik feladat pontosan ez (a HW NAT tesztelése V6-tal PPPoE felett9. Van esetleg valami iránymutató írásod a témában? Korábban már mintha linkeltél volna valamit a többeiknek.
-
válasz
zsolt_64
#99254
üzenetére
Ez attól függ, hogy melyik SoC vendor milyen platformja van az adott routerben. Az RT-N66U B1 és B2 mind Broadcom chipet tartalmaznak, én ezeket nagy ívben elkerülöm. Azt nem hiszem, hogy nincs bennük valamilyen szintű hardveres gyorsítás, de az is lehet, hogy PPPoE-n nem működik valami jól.
Az RT-AX86U megint Broadcom alapú, tehát a biztosan van benne gyorsítás, a kérdés hogy elég jó-e.
Az hogy hány LAN gépet tud kiszolgálni egyszerre az a belső felépítésétől függ: például több esetben is láttunk már olyan routert, amiben a 2.5G WAN port és a switch között gigabites interfész volt, tehát LAN irányban összesen 1 gigabitet tudott forwardolni, így két gépen is csak összesen 1 gigabit elérhető. Viszont AX wifi plusz LAN-on lévő gép egyszerre tudott többet mint 1 gigabit. Ezt akkor lehet eldönteni, hogy kiderül, hogy az adott routernek milyen a belső felépítése, nem annyira a HW NAT-tól függ.
Tudom, ez nem sok vígasz, de pillanatnyilag nehéz megmondani. Én a helyedben picit kivárnék a router vásárlással, amíg tisztul a kép. Karácsony előtt amúgy sem szaad venni semmi ilyesmit

-
válasz
MasterMark
#99247
üzenetére
Nem szeretném a topikot filozófiai irányba elvinni, de azért felteszek egy kérdést: amikor azt látod, hogy az újabb "technológiák" csak úgy tudnak érzékelhető sebesség növekedést elérni, hogy növelik a csatorna sávszélességet - mert már minden más szóba jöhető dimneziót kihasználtak és ezzel megközelítették a közeg fizikai korlátait - , akkor mi korlátoz végső soron: a technológia vagy a közeg?
A koaxos példánál maradva: tudod miért fejlődik a CATV hálózat a mikro-szegmentálás irányába? Pontosan azért, mert a technológia már nem tudja leküzdeni a közeg által meghatározott fizikai korlátot. Így az egyetlen lehetőség a nyers erő. Ebben az esetben nagyobb sávszélesség, rövidebb réz szakaszon. Wifi ugyanez: 80 helyett 160MHz. A többi fejlesztést csak marginális 5-10-15%-os javulást hoz. -
válasz
MasterMark
#99242
üzenetére
Értem hogy hogy értette, csak nem jól fogalmazta meg

Mondjuk a wifis példából kiindulva: változik attól a közeg átbocsátó képessége, hogy 64 helyett 256QAM-ot használunk? Vagy attól, hogy 20 helyett 80 vagy 160MHz-es sávszélességet használunk? Esetleg a MIMO miatt megdőlt a Shannon-szabály? Nem. Csupán - optimális körülmények között (!) - több bitet tudunk átsajtolni ugyanazon a közegen. A keretet tehát nem a technológia, hanem a közeg adja meg végső soron.
-
válasz
MadMancs
#99239
üzenetére
"nem a közeg hanem a technológia szab határt"
Valójában a közeg szab határt, ami engedelmeskedik a fizika törvényeinek. Amit a technológia csinál "csak" annyi, hogy megpróbálja ezt a keretet feszegetni újabb és újabb dimenziók kiaknázásával, alulról megközelítve annak határát. De átlépni soha nem fogja azt.
-
-
válasz
Cirbolya_sen
#99224
üzenetére
Otthonra nincs. Nem offload-ol olyan protokolokat a szerverbe szánt kártya, amikre neked otthon szükséged lehet. GENEVE/VXLAN/MPLS, néhány egyéb egzotikus core protokol mint a GTP, ezek neked otthonra nem sokat érnek, viszont a beépített FPGA-t meg kell fiezni. Szerintem bármilyen kártyát lehet venni, úgy is 1-2 gyártó chipje lesz rajtuk, amiket már elég nagy számban adtak el ahhoz, hogy legyen tisztességes támogatás meg driver hozzájuk. Nem gyártanak olyan sokan 2.5/5G/10G képes chipseteket, hogy nagy legyen a választék

-
válasz
Multibit
#99219
üzenetére
Még szép. Az egész NPU lényege az, hogy kikerülöd a kernelben lévő hálózati infrastruktúrát, ezért sokkal gyorsabb a forwarding. Az IPQ807x szériában az NPU elég fejlett, így például shapinget, Cake-et ilyesmit lehet vele használni, de hogy ez például mikor lesz OWRT-ben elérhető, az erősen kérdéses. Pillanatnyilag örülünk neki, hogy megy a NAT meg a PPPoE offload. DPI szerintem sosem lesz HW gyorsított egy közép kategóriás SoC-ban.
-
válasz
Multibit
#99210
üzenetére
Erről beszéltem. Én semmi jelét nem látom annak, hogy ez a probléma belátható időn belül megszűnjön. Bár a személyes tapasztalatom az hogy úgy általában, és ezen a fórumon is sokan túlbecsülik a PPPoE által okozott többlet terhelést. A PPPoE önmagában egy végtelenül egyszerű protokol, nem okoz számottevő többlet terhelést beágyazott rendszereken sem. A valódi probléma a NAT és forwarding performancia (ez már több-szálas végrehajtásban működik), itt viszont - főleg a megfizethető, elfogadható fogyasztás miatt - csak az NPU jöhet szóba, ha gigabit fölötti sebességről van szó.
-
válasz
Multibit
#99178
üzenetére
"A PPPoE kezelést áltatában az oprendszer intézi"
Hát persze... A kernel intézi, nem az OS, és ez nem FreeBSD sajátosság. A PPPoE egymag limitet tényleg jó volna felszámolni, de ezt nem a freebsd vagy a freebsd kernel fogja megoldani, max backportolják linuxról. Én nem tudok arról, hogy bárki is foglalkozna ezzel, legalább is nyoma a kernel forrásban egyelőre nincsen. De persze ez nem zárja ki, hogy valaki dolgozik rajta, ha van forrásod, szívesen elolvasnám.
-
válasz
Multibit
#99171
üzenetére
Alapvetően nincs. X86-on általában a hálózati kártyák képesek bizonyos szintű gyorsításra, de azt látni kell, hogy ezek a megoldások nem hasonlíthatók össze a korábban már vázolt megoldásokkal, és az esetek nagy részében nem a NAT vagy forwarding peformancia, hanem elsősorban a szerver oldali és adat centerekben használt protokolok gyorsítása a cél. Ezek a megoldások keveset érnek mondjuk ha magadnak építenél otthonra egy routert belőlük. PPPoE offload például egyikben sincs. NAT offload szintén nincs. Tehát ezekben az esetekben a processzornak erőből kell megoldania a dolgot, illetve a SW offload megoldásokra lehet támaszkodni, bár az erősen kérdéses, hogy 10Gbit PPPoE forgalommal mit tudnának kezdeni... Ennél is nagyobb gond, hogy bizonyos protokolok de/enkapszulálása még mindig egy maghoz kötődik (PPPoE), tehát hiába veszel 10magso procit, nem mész vele semmire ebben az esetben. Én azt gondolom, hogy épeszű, relatív megfizethető megoldások csak SoC köré épülhetnek. Minden más drága lesz, sokat fog fogyasztani és ha képes is kiszolgálni ezt a sebességet, hatékony biztosan nem lesz.
-
-
válasz
Cirbolya_sen
#99144
üzenetére
Egyik beágyazott rendszer sem elég erős ahhoz, hogy kinyomja magából a NAT-ot szoftverből, főleg 10gigabiten nem. Ezek a sebességek csak NPU-val, PPE-vel, vagy egyéb komolyabb "hardveres" gyorsítással érhetőek el. Ezért is kár a magszámot meg az órajelet lesni. Az a kérdés hogy mennyire jó az NPU implementáció. IPQ8071A-n gigabit PPPoE NAT mellett a 4 ARM mag 0-1% körül mozog, tehát nincs terhelés. Pontosan ugyanez az NPU van az IPQ8072A-ban is, tehát biztosan kijelenthető, hogy könnyedén ki fogja tolni magából a 10gbit NAT-ot akár PPPoE-n is.
-
válasz
WaterWave
#99140
üzenetére
Én nem félek attól, hogy nem lesz kellően erős SoC a 10gbit-hez, mert már most is van ilyen a felső-közép kategóriában:
A probléma azzal van, hogy jellemzően ezek köré pérmium routereket építenek, amikhez drága a tri-band wifi chip meg a 6GHz-es RF blokk (egyelőre). Ha pusztán a vezetékes részt nézem, akkor az IPQ807x-ben van 4 ARM mag, bár ez tök mindegy, mert ezeket a sebességeket csak PPE-vel és NPU-val lehet kezelni, tehát nem a SoC alkalmazás-processzorának a feladata a NAT-oást és tűzfalazást, esetleg a forgalom priorizálását kezelni, ergó mindegy hogy hány GHz-es meg magos a SoC. :-)
-
válasz
TeeJay
#99103
üzenetére
"Gyanítom így fogják csak azokat rákötni a 10XGSPON-ra akik arra fizetnek"
Ház az elég nehéz lesz, mivel a splitterek jellemzően nem az OLT mellett vannak. A PON-nak pont ez a lényege, hogy nem pont-pont kapcsolat van az OLT/CO és az ügyfelek között.
A saját router témában szerintem mindenki elmondta már a véleményt, a hittérítéstől viszont ha lehet tartózkodjunk a jövőben. Mindenki el tudja dönteni saját maga, hogy mit szeretne.
-
válasz
TeeJay
#99089
üzenetére
Kizárt, hogy új OLT típust vezetnek be. A meglévőket bővítik. Arról nem beszélve, hogy a Zyxel OLT-it mind kicsik. A Diginek ennél sokkal nagyobb sűrűség kell...
Az ONT-be való modul elméletileg átrakható, és mivel ezek az ONT-k jellemzően tudnak AON-t is, így jó esélyel a GPON MAC bennük van, tehát a "komplett" ONT a modulon fut. Persze hogy a mindenféle vendor proprietary megoldás miatt át tudnád-e rakni mondjuk ag Ubi vagy Mikrotik cuccba, az azért erősen kérdéses.
-
-
válasz
Lajosnagy17
#98888
üzenetére
Gamereknek RGB ONT-t tudok ajánlani ötszörös áron, mivel az már kiderült, hogy minden szart megvesznek ész nélkül

-
válasz
MasterMark
#98844
üzenetére
Már miért ne lenne?
-
válasz
TeeJay
#98786
üzenetére
Plusz egy ezresért én is benevezek majd rá, és nem fogok agyérgörcsöt kapni, hogy "csak" gigabittel fog menni. Ha az XG-PON miatt kicsit javul a csúcsidei stabilitás, akkor már megérte. A fejlesztére ettől függetlenül is szükség volt, nem hiszem hogy kizárólag az XG-PON miatt csinálták.
-
válasz
viktorhu
#98743
üzenetére
Mutatom: [link]
Tehát a GPON és az XG-PON egymás mellett léteznek, ugyanazon az üvegszálon de más hullámhosszon. Nem kell cserélni semmit, a régi GPON eszközöbe az új hullámhosszak szűrése be van építve. Az OLT oldal érdekesebb, mert jellemzően ma még kevés a combo port (ami egy optikai porton tud mindent kitolni), így az elején lehetséges hogy külön kártyákról fog jönni a kettő és egy duplexer fogja az OLT oldalon össze illetve szétválasztani a különböző hullámhosszakat. Ez az előfizető szempontjából persze lényegtelen.
Az XG-PON - mivel lényegében egy teljesen új infrastruktúra, már ami az előfizető felé néző lábat illeti - annyi előnnyel biztosan bír, hogy az elején kevés előfizető fogja terhelni, mert a többség marad GPON-on.
Ha bevezetnének is 1/1-es csomagot (ami nem valószínű ha az árazást nézed), akkor is célszerűbb ezeket XG-PON-ra tenni, mivel a GPON maximális feltöltési kapacitása és a jelenlegi osztási arányok baromi hamar túlterhelnék a jelenlegi GPON részt.
-
"Ez teljesen indokolható igény lehet, amire megfelelő lenne egy 1Gbps szimmetrikus csomag, ami nem igényel technológia váltást lan oldalon."
Attól, hogy 2.5gigás csomagod van (plusz egy ezresért) senki nem tartja a pisztolyt a fejedhez, hogy kicseréld a LAN-t, ha neked elég a gigabit, és felhős használat mellett megháromszoroztad a feltöltésedet. Pont az a vérpistikés hozzáállás, hogy csak akkor tudsz elképzelni egy 2.5gigás csomagot, ha valaki ezt csontra ki is tudja tekerni...
A butasághegyet te kezdted el a torrentes és vérpistikés megjegyzéseddel, így a gondolkodást neked ajánlom.
-
"Valszeg torrent pistike a célközönség, meg farokméregető speedtest andriska. "
Micsoda elképesztő ostobaság ez... Én például szívesen fizetnék egy ezressel többet a 2.5gigáért, csak hogy a jelenlegi 300 helyett 900-zal tudjak feltölteni havonta pár alkalommal, amikor a munkám miatt ez szükséges. Az is simán megérhet plusz egy ezrest, hogy XG-PON-on legyek, ami jóval kevésbé fog torlódni.
A farok méregető meg a torrentes pont nem fog beruházni egy valag pénzt 10gigás otthoni hálózatba (meg olyan háttértárba ami ezt ki is tudja szolgálni), azok ugyanis csak pofázni szeretnek róla, súlyos pénzeket elkölteni nem.
-
Ez a hazai csatornákra talán igaz lehet, de a csatornák többségére biztosan nem. Bár jobban belegondolva: a hazai csatornáknál is nehéz elhinni, hogy valaki nem csak sötétszálat, de HD-SDI-vel kompatibilis erősítő láncot is beruház ezen a sötétszál nyomvonalon. Akárhogy is, ez csak kis távolságon és marha drágán működik.
-
Itt fogalmi zavar van. A szó broadcast értelmében vett tömörítetlen jelet senki nem ad vagy kap, az a HD-SDI lenne. Annyi igazság azért van a dologban, hogy a szolgáltatók sokkal jobb minőségű jelfolyamhoz férnek hozzá, mint amit aztán szolgáltatásként tovább értékesítenek, de ettől még az tömörített marad.
-
Nem bukott meg, csak nem volt időszerű, 2010-ben semmiképp. De ahogy a DVB-T2 és S2 terjed (nem véletlenül), és nem végezte ki őket az IPTV, úgy a C2-re is szükség lesz, például a korábban már vázolt 4K témában a DVB-C egyre inkább szűk keresztmetszet lesz. Akkor működik hatékonyan az átvitel, ha viszonylag nagy csatornasávszélesség mellett sok csatorna fér el, mert így sokkal jobban kihasználható a rendelkezésre álló kapacitás a VBR miatt. ha csak 2-3 csatornát tudsz összerakni egy blokkba, az elég látványosan rontja az átvitel hatékonyságát. Ez persze nem neked, hanem a szolgáltatónak fontos.
-
-
-
válasz
TeeJay
#98297
üzenetére
Alapvetően az a kérdés, hogy egy csatornát mekkora bitrátával akarnak tolni. DVB-C-n egy 8MHz-es csatorna maximális kapacitása 50Megabit körül van. Ha te erre H.264-ben akarsz 4K-t rakni, az azt jelenti, hogy egyetle csatorna lényegében megkajálja a kapacitást. Összességében (több csatorna esetén) ez a megoldás baromira nem hatékony. Ha H.265 mellett bele tudnak nyomni legalább 3-4 adót ebbe az 50megabitbe (amire azért van esély), akkor már jó lehet a dolog DVB-C-n is. Elvi akadálya nincsen egyébként, a kodeknek nincs semmi köze ahhoz, hogy DVB-C-n, vagy C2-n tolja a szolgáltató. És tekintve, hogy a Diginél RF Overlay miatt gyakorlatilag használhatják a teljes catv spektrumot, így hely van bőven (már ha más szolgáltatókkal hasonlítod össze).
-
válasz
ElektrikusDE
#98260
üzenetére
Ki merem jelenteni, hogy nincs a bolygón olyan GPON ONT, amit ne lehetne bridge-be rakni. Ugyanis ez (az L2 funkció) egy ONT legalapvetőbb feladata. Maximum annyiról lehet szó - ha egyáltalán igaz a hír - hogy még nem fejezték be az ONT integrálását, de biztosan hamar megoldják. Integráltam már Nokia, AVM, Genexis, Huawei és ZTE ONT-ket (külön-külön több típust is a fenti listából), de soha olyannal nem találkoztam, ami ne tudta volna a bridge módot. Ellenben láttam már olyat, ami nem is tudott mást, csak bridge módot.

-
válasz
TeeJay
#98241
üzenetére
Senki nem tol 4K-t mpeg4-ben. H.265 lesz, ha lesz belátható időn belül, és nincs semmi akadálya, hogy ezt DVB-C-n tegyék, bár valószínűbb hogy DVB-C2 lesz az L1. A nagy előnye az RF overlay-nek, hogy nem kell cserélni semmit optikán, csak új STB vagy alkalmas TV kell, meg egy központi OFDM modulátor blokk.
-
-
Itt valami logikai bunkfenc van. Azt kérdezte a -23dBm jó-e. A válasz: igen, jó. Hogy lett ebből -8 meg -10dBm? Ha a műszeres mérés és a modem által riportált érték között nagyobb az eltérés, mint 2dB, akkor ott valami nem kerek.
Az meg, hogy mi az ami "elmegyeget" kevéssé érdekes. Ami biztos, hogy -28dBm alatt, és -8dBm felett riaszt az OLT, tehát a kettő között fogadható el, ezt egyébként rögzíti a Class B+ optikai modulokra vonatkozó szabvány is. FEC-cel akár -30dBm alatt is "elmegyeget", de ettől még nem fogadható el egy ilyen eredmény

-
Esküdni mernék, hogy a nálam lélvő AX6 dobozára az AX3000 felirat is rá lett nyomva, de ezt majd megnézem ha hazaértem. Nálam január óta van meg. Mondjuk ezt sosem értettem, hogy ugyanannak a terméknek miért van két neve, bár ez még mindig jobb annál, mint mikor két különböző terméknek van megegyező neve.
-
-
válasz
Dragon3000
#97520
üzenetére
Mi voltunk a hülyék, de egészen más okból...

-
Ha a laptop nincs tápra duva, számos alkalommal láttam már kiábrándító eredményt. Ráadásul hiába nézed ebben az esetben a procit terhelést is, mert a limitáció nem ott, hanem a PCIe interfészen lesz az energiagazdálkodás miatt. Volt olyan laptophoz is szerencsém, ami tápra dugva is csak a profil megváltoztatásával volt hajlandó kitekerni magából a gigabitet.
-
-
válasz
woodworm
#97284
üzenetére
Küldesz ehhez valami típusszámot vagy azonosítót? Nem rémlik, hogy bármit is átlakaítottak volna az mt7621-en.
adika4444:
Nem véletlenül váltottam én is IPQ8074-re. De ez végképp nem egy kategória az mt7621-gyel. Nekem az mt7621 sebességével nem volt gondom, minden mással viszont igen. Vacak wifi, random hibák a switch driverrel stb.
Az IPQ8074 még elég új, tehát azt nem mondom, hogy teljesen hibátlan a történet, de az elmúlt fél évben többet haladt a dolog, mint az mt7621 5 év alatt.
-
-
Ezek az állítások még California egészére sem igazak, nem hogy országos átlagban. Tudod, Califronia nem egyenlő a szilícium völggyel meg a közvetlen környezetével, ahol egyébként elképesztő jólét koncentrálódik nagyon kis területen. De hát nyilván a texasi farmer seggéből is optika lóg ki egy olyan országban, ahol simán előfordul hogy a 6 sávos autópályán nincs mobil lefedettség sem két nagyobb város között...
-
Ja, az előfizetői kör 0.000001%-án, a többi meg szívhat az ezeréves DOCSIS-szal, 10-20megabites max feltöltéssel, meg az AT&T féle fostos DSL-lel, horror áron. Egyáltalán nem olyan fényes az USA telkó helyzete, különösen ha az ország egészét nézem, és nem csak egy két jobb módú és sűrűn lakott környéket.
-
válasz
Bizsu1st
#96216
üzenetére
Eszemben nincs visszaolvasni. Senki sem olvas vissza, ezért generálják a sok felesleges hozzászólást, ami viszont az én időmet is rabolja. Hármat visszaolvasok és levonom a következtetést. Ilyen világot élünk, tessék megszokni. Ezért hagytam abba a logout-os cikkek írását is, nincs semmi értelme ide minőségi kontentet gyártani. 3-400 hozzászólásonként kipuffogom magam és kész. Erre pont jó, egyébre nem.
-
válasz
4Grider
#96210
üzenetére
MÉg ez sem probléma. Az viszont igen, hogy azután is köti az ebet, miután leírták neki hogy kábelen mérjen. Ezt egyébként eleve soha nem értettem, hogy valaki nem ért valamit, jön a fórumba segítségért, majd amikor választ kap, neki áll szakérteni. Most akkor vagy tudja a választ és minek fórumozik, vagy nem tudja a választ és tudomásul veszi, hogy mások tudására van utalva.
-
Nézd, a hivatalos link budget -28dBm-nél húzza meg a határt. Ez FEC nélkül értendő, nyilván ha van FEC, akkor 1.5-2dB-t még rá lehet rakni, de a legtöbb OLT alarmozik -28dBm alatt, nem véletlenül. Nálunk van FEC, de -26dBm alatt nem veszek át egyetlen végpontot sem, mert nem maradna semmi tartalék a rendszerben (ennek évekig működőképesnek kell maradnia, a kábel öregszik, vagy kábelátvágás javítása után nő a csillapítás amúgy is). Szóval igen, a -28dBm is nagyon a határon van.
-
válasz
leviske
#96048
üzenetére
Egy túrost ilyen. Szarul szerelik, aztán ha nincs látványos panasz, akkor úgy tesznek mint ha minden rendben lenne. Nálam -21 a vételi, ezt műszerrel is ellenőriztem, a modem nem téved sokat. Az hogy nálad -34-ről "javították" -28-ra, az azt jelenti, hogy szarul csinálták meg annó, ezt át sem lehetett volna adni.
-
válasz
leviske
#96046
üzenetére
" akkor -34-ről -28-ra javították a jelet"
Nem csoda hogy szakadozott, a -28 is határeset, -34-nél még nem láttam jól működő PON kapcsolatot FEC mellett sem. El tudom képzelni, hogy az uplink milyen lehetett, ha az ONT vételi oldala ilyen siralmasan gyenge volt...
A hibakivizsgálást eleve a szintek ellenőrzésével kéne kezdeni.
-
-
-
válasz
turulbird
#96002
üzenetére
"Plussz energiatartaléknak mindig kell lennie az esetleges áramfelvétel megugrások miatt."
Édes faszom, és te magyarázok itt a fiizkáról...Ez megmosolyogtató, ahogyan a gyermekded példád is. Szerintem ez nem az óvoda, egy érettségit mindenkinek megelőlegezek
A kérdésemre a válasz: nem, nem mérted meg, csak a gyártó verzióját mantrázod, amiből nem mellesleg megint az derül ki, hogy USB nélkül még az elméleti maximumba is belefér 12V/1Amperrel a router. Nálad nem az a probléma, hogy kevés a táp, hanem az hogy szar a táp (már ha egyáltalán ez okozza a problémádat).
-
-
-
-
Nálam F668 megy mostmár lassan 5 éve, a gyári tápját már javítani kellett, kondi kiszáradás. Viszonylag meleg helyen van, de a levegő jár körülötte. Ez 2 éve volt. Szétszedtem, de belül nem volt gond. 1-2 kondit meg is értem, minden gyári értéken volt. Ha van alkalmas táp a közelben és gyorsan kell a net, akkor érdemes lehet másik (kompatibilis!) táppal megpróbálni.
-
Gdrive-ra 30-40megabittel tudok feltölteni, korábban kimaxolta a 300-at. Érdekes, hogy francia IP-re megy a forgalom...
-
-
válasz
satmen
#95677
üzenetére
Már a sokadik alkalom, hogy az USB --> Ethernet átalkaítók sebességét firtatja valaki. Nos, az USB3-mas ethernet átalakítók nagyja Realtek chipsettel szerelt, teljesen és tökéletesen alkalmas a gigabites sebesség átvitelére. Probléma leginkább akkor van, ha a user USB2 portba dugja, akkor 350-400Mbit érhető el lefelé, felfelé némileg kevesebb. Nálam is egy filléres Ali-s átalakító van, remekül átviszi a gigabitet mindkét irányban, PPPoE-vel is. Nem jobb, vagy rosszabb mint bármilyen alaplapra szerelt hálózati kártya (ugyanaz a chipset egyébként, csak a busz vezérlő a különbség).
A helyes kifejezés pedig: krimpelés, R betűvel. Az angol crimp kifejezésből származik.
-
-
-
válasz
Lajosnagy17
#95471
üzenetére
Feltehetném a kérdést, hogy a belső 2. és 3. kerületet mikor tervezik végre elkezdeni, mert megígérve 5 éve meglett, de egy méter el nem készült belőle. Pedig kaszálni lehetne, mert csak Telekom van, abból is szénné torlódó DOCSIS. Utca végén van Digi 10 éve, de nem jött közelebb ennyi idő alatt sem.
-
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
- Samsung Galaxy Felhasználók OFF topicja
- A fociról könnyedén, egy baráti társaságban
- Eredeti játékok OFF topik
- Lexus, Toyota topik
- Gitáros topic
- Soha nem szabta ilyen pénztárcabarátra új CPU-it az Intel
- Windows 10
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Amlogic S905, S912 processzoros készülékek
- További aktív témák...
- Beszámítás! Asus TUF A16 FA608UH FHD Gamer notebook - R7 260 16GB DDR5 512GB SSD RTX 5050 8GB
- Akciós kisWorkstation! Dell Precision 3570 i7-1255U 4.7GHz / 16GB / 512GB / Quadro T550 4GB FHD 15"
- Apple iPhone 14 Pro Max / 128GB / Kártyafüggetlen / 12Hó Garancia / Akku: 100%
- Apple iPhone 14 Pro 128GB,újszerű, Adatkabel,12 hónap garanciával
- Telefon felvásárlás!! iPhone 14/iPhone 14 Plus/iPhone 14 Pro/iPhone 14 Pro Max
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest



