- Samsung Galaxy S21 Ultra - vákuumcsomagolás
- Yettel topik
- iPhone topik
- Digitális detox a Nokiától
- Honor Magic6 Pro - kör közepén számok
- Motorola Edge 40 - jó bőr
- Realme GT Master Edition - mestermunka
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Apple iPhone 11 - népalma
- Redmi Note 12 Pro - nem tolták túl
Hirdetés
-
Xbox Game Pass [2024] - A májusi lista
gp Az elkövetkező időszakban többek között megkapjuk a Kona II Brume című játékot.
-
Új Beats fej- és fülhallgatók jelentek meg
ma Frissítette a Solo termékcsaládot az Apple házi audiomárkája.
-
Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
ph A cég megoldása centralizált vezérelhetőséggel, masszív radiátorral és robusztus ventilátorokkal igyekszik vásárlásra csábítani.
Új hozzászólás Aktív témák
-
dchard
veterán
Jó kérdés.
A mérés elméletileg előre irányú (tehát a központ felől mér a modem felé), elképzelhetőnek tartom, ahogy egyre magasabb frekin nő a csillapítás, úgy egy bizonyos ponton az egyre kisebb frekin megfordul ez a csökkenő tendencia valamilyen fizikai tulajdonság miatt.
Könnyen lehet, hogy ha vissza irányban csinálnánk freki menet vizsgálatot, akkor meg az uplinknél lenne a legalacsonyabb a csillapítás.
De ez csak spekuláció
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
Intruder2k5
MODERÁTOR
Nálam a modem LAN IP címe az alap 192.168.1.1 volt, a routeré meg egy teljesen más tartományba esik... (192.168.53.11) Annyit kellett tenni, hogy a tűzfal scriptbe betenni ezt a két sort:
ifconfig `nvram get wan_ifname`:0 192.168.1.2 netmask 255.255.255.0
iptables -t nat -I POSTROUTING -o `nvram get wan_ifname` -j MASQUERADEEzzel a WAN interface kap egy 192.168.1.2-es címet, amiről már elérhető routeren keresztül az ADSL modem. De ez csak moddolt firmware-el járható út...
[ Szerkesztve ]
-
dchard
veterán
Melyik részét?
Például amikor driver támogatást kellett csinálnom új flash memóriákhoz, az ansi C volt, de a webes felület scriptjeit CGI-ben és HTML-ben csináltam, a különböző parancsok vezérléseihez tartozó scriptek jellemzően (b)ash-ben íródtak. Azt tudni kell, hogy a C-t kivéve az összes nyelvnél komoly limitációk vannak/lehetnek a beágyazott rendszereken futó verzióknál.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Ehhez kicsit jobban meg kell érteni a beágyazott rendszerek tipikus működését:
1. A flash memória kevés bennük, ezért a memóriát jellemzően a bootloader partíciókra osztja. A Broadcom-nál CFE a bootloader és a memóriát négy részre osztja:
bootloader
bootloader NVRAM <-- itt vannak a bootloader beállításai
rootFS <-- itt található lényegében a firmware image tömörítve (squashfs)
generic NVRAM <-- itt találhatóak a firmware által használt beállításokNamost mivel az egész rootfs kerenelstől mindenestől be van csomagolva, a bootloader azzal kezdi a rendszer indítását, hogy fogja és kicsomagolja a rootFS-t a memóriába, utána meghívja azt a memóriacímet, ahol a kernel eleje található és már indul is a rendszer. Ezért van az, hogy 6MB-ot mond a rendszer max memóriára, pedig 8MB van a nyákon. Ugye 2MB körül van a firmware ezt kicsomizza a memóriába, tehát a 8MB-ból marad 8-2=6MB.
Külön NVRAM terüetre azért van szükség, mivel a rendszer futása közben írni csak azt a kis részt lehet, hiszen maga a rootfs tömörítve van.
Namost a bootloader és a hozzá tartozó nvram fix, de a másik kettő arányát lehet változtatni, viszont csak a másik kárára. Jellemzően 32-64KB NVRAM a rendszernek untig elég.
És igen: amikor a firmware lefordul akkor a megfelelő alkalmazás összegyúrja a kernelt és a rootfs-t, betömöríti stb. és előállítja az a formátumot, amit a modemben lévő BCM hardver kezelni tud, lényegében eneka folyamatnak a vége a fájl amit firmware-ként emlegetünk.
Dchard
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Ehhez még annyit, hogy nálam egy 12Voltos VDSL2 modem amikor csak 10 Voltot kapott, nekiállt rebootloni, pedig az ampert megkapta amit kért... Ez az ún. dying gasp funkció, így tudja a modem hibás táp vagy áramszünet esetén értesíteni a központot, hogy ő most nem megszakadt, csak elment az áram.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
Hix3r
csendes tag
DMT v8.07-el tudsz csak kapcsolódni a v9.01 verzióval nem működik (ha megnézed a honlapján csak a 8.07-es támogatja a BCM 6338 chipsetet), ezt a kört már én is megjártam
"It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so."
-
dchard
veterán
Ha volnál olyan jó és csinálnál egy nagy felbontású fotót a modem belsejéről akkor beljebb volnánk. A lényeg, hogy a chipeken látható feliratok olvashatóak legyenek. Nekem nagyon gyanús, hogy ebben nem broadcom chip van, ha pedig ez a helyzet akkor ez az első olyan 321B amivel nem fog menni a firmware-em.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Bontsuk ketté a dolgot:
1. Az ADSL fizikai rétege, amint érzékeli a LOS-t, azonnal alaphelyzetbe áll, és ismét megkísérli a kézfogást és az újracsatlakozást. Meglehetősen jól definiált ez az állapot gép, nem láttam még ezzel kapcsolatban problémát.
2. A PC vagy router PPPoE része már lehet gázos, beragadhat a tárcsázási folyamat stb.
Szóval ha a modem a ledek alapján újrakapcsolódott, akkor érdemes ránézni a routerre, ami alap esetben always on, vagy auto reconnect vagy erre hajazó módba kell tenni (nem manual, vagy on demand módba).
Amenniyben a router nem kapcsolódik újra, akkor restart, illetve szoftver frissítés lehet a megoldás.
Persze előfordulhat, hogy a szélben folyamatosan elmozduló kötés vagy kábelhiba miatt egyszerűen álandóan szakad a kapcsolat, ezt a modem megfelelő állapot LED-jéből lehet kideríteni (a modem állandóan vagy sűrűn újraszinkronizál).
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Nem, az 1 perc körüli idő teljesen normális. Kb. 30-40 sec. a DSL fizikai réteg, és utána még a PPPoE démonnak is rá kell jönnie hogy mehet a menet, az újabb pár sec, szóval az egy perc az elfogadható.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
J.K.F.
tag
Nincs ezzel semmi baj, csak "színezési probléma".
Valamiért abban a hitben van az OrbMT, hogy Annex A-s (PSTN) ADSL-ed van, pedig valójában Annex B-s (ISDN), ezért rossz frekvenciatartományt festett ki Upload-ként ( [Wikipedia] ).
[ Szerkesztve ]
-
J.K.F.
tag
Alapvetően a pillanatnyi SNR értékeket veszi figyelembe vivőnként.
Vivőnként kiszámolja, hogy adott (a programban beállított) SNR margin mellett egy-egy vivőn hány bitet lehetne átvinni a vivőn mért pillanatnyi SNR értékek mellett. Ezt szummázza az összes vivőre, így kapunk egy bitszámot. Ebből levonja a nem nulla bitet átvinni képes csatornák számnak a felét (kb), majd megszorozza néggyel (4kHz symbol rate), majd megszorozza egy "efficiency" értékkel, ami amolyan "legideálisabb eset" a hasznos bitek számát illetően egy FEC frame-en belül:
- B (number of bytes in Mux Data Frame): 244
- M (mumber of Mux Data Frames in FEC Data Frame): 1
- T (Mux Data Frames over sync bytes): 2
- R (number of check bytes in FEC Data Frame): 10
- FEC Data Frame Length : (B+1)*M+R = 255 -> Efficiency = 244.5/255 ~ 0.958824Hogy miért pont így számol? A kiindulópont az volt, hogy elegendő lenne az adott SNR margin mellett kiszámolni, hány bitet lehet átvinni az összes vivőn, és ezt 4-gyel megszorozva (4kHz symbol rate) már meg is kapom a bitsebességet kbps-ben kifejezve. De ez legtöbbször igen közeli értéket adott a modem által tippelthez (amit egyébként a modem nem így számol, hanem a szabványban leírt nagyon kacifántos módon), ami nekem nem tetszett. Továbbra azt se magyarázta meg, hogy hogyan fordulhat elő, hogy SNR lock esetén látszólag ugyanolyan magasak a "bits" oszlopok, mégis sokkal kevesebb a vonal bitsebessége mint normál esetben.
Először is azt vettem észre, hogy a mikor "korlátozva van" a vonal, az abban nyilvánul meg, hogy a fentiekben általam kitalált "Efficiency" értéke rémesen rossz: pl. a MUX data frame-ek elég rövidek, nagyon alacsony a B (hasznos adatbitek) értéke, stb. A max sebesség becslésnél a fenti legideálisabb esetet feltételeztem, akikor a FEC dataframe-ben jó magas a hasznos bitek száma, a neten eddig modemstatisztikában látott legalacsonyabb hibajavító bitszám mellett. Legalábbis remélem, hogy jól bogoztam ki a keretezés mikéntjét.
Ez volt tehát az Efficiency az egyik "rontó" szorzó. A másik "rontó" dologra csupán egyetlen helyen találtam valami halvány utalást, ez az amikor a nem null bitet átvinni képes vivők számát elosztom kettővel és levonom az összes átvitt bit számából. Bár csak egyetlen helyen találtam rá utalást, hogy ezt a kivonást el kell végezni, de elég jól illeszkedett arra a fura anomáliára, hogy az "Info"-ban az "L" értéke miért nem egyezik hajszálpontosan (hanem mindig következetesen jelentősen alacsonyabb) azzal a számmal amit akkor kapnék, ha szummáznám a vivőnként átvitt bitek számát a "Bits" táblában szereplő értékeknél.
[ Szerkesztve ]
-
dchard
veterán
Letiltották az Annex J, mert esetleg van még ISDN vagy analóg előfizetés a törzskábelen.
Hozzáteszem: az általam írt firmware annex J-t sosem támogatott, csak annex M-et, bár annex J módban sosem teszteltem mivel a DSLAM szimulátorom nem támogatja az annex J-t. Tehát akár még működhet is.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
-
-
Új hozzászólás Aktív témák
- MAIWO NVMe + 2.5"/3.5" SATA SSD/HDD dokkoló és klónozó - Dobozos, újszerű
- MÁSFÉL DARAB: NEM PÁR! ÚJ Heco Concerto Grosso Ultra High End hangsugárzó! 63kg/db! 16Hz-52 kHz!
- APC Back-UPS PRO 900VA BR900G-GR - Dobozos, újszerű
- Samsung Galaxy A21S telefon eladó
- Apple iPad 9 Tablet (2021) - bontatlan, 2 év garanciával kibontástól számítva