- Samsung Galaxy S24 FE - később
- Huawei Watch GT 6 és GT 6 Pro duplateszt
- iPhone topik
- Yettel topik
- Samsung Galaxy S23 Ultra - non plus ultra
- Samsung Galaxy S25 - végre van kicsi!
- Xiaomi 13 - felnőni nehéz
- Apple Watch Sport - ez is csak egy okosóra
- Apple Watch
- Samsung Galaxy A56 - megbízható középszerűség
Új hozzászólás Aktív témák
-
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
-
J.K.F.
csendes 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.
-
J.K.F.
csendes 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] ).
-
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
-
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
-
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
-
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
-
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
-
#967
Intruder2k5
MODERÁTOR
weiss
#966
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...
-
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
Új hozzászólás Aktív témák
- Samsung Galaxy S24 FE - később
- Hobby rádiós topik
- Építő/felújító topik
- gban: Ingyen kellene, de tegnapra
- Logitech Harmony - én irányítok mindent!
- Formula-1
- BestBuy topik
- Kínai és egyéb olcsó órák topikja
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- EAFC 26
- További aktív témák...
- BESZÁMÍTÁS! MSI B760 i7 13700K 32GB DDR4 2TB SSD RTX 4080 16GB be quiet! 500DX Seasonic 750W
- BESZÁMÍTÁS! ASUS H510M i5 10400F 16GB DDR4 512GB SSD RTX 3060Ti 8GB Zalman S2 TG CHIEFTEC 700W
- PS5 The Last of Us limitált kontroller, bontatlan, garanciális
- Steelseries Apex 5 Blue Switch US Mechanikus Billentyűzet
- Asus ROG PG248Q 24" 180Hz
- Gamer PC- Számítógép! Csere-Beszámítás! I7 4790K / 16GB DDR3 / RX 5700XT 8GB / 512GB SSD
- Bontott, vadiúj, SKY BLUE MacBook Air 13.6" M4 10C/8G 16GB 256GB 13 Gar.: 1 év APPLE világgarancia
- iPhone 11 Pro Max 256GB Midnight Green -1 ÉV GARANCIA - Kártyafüggetlen, MS3261, 100% Akkumulátor
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB DDR5 RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest