Új hozzászólás Aktív témák

• #2838 J.K.F. csendes tag weiss #2837

  Új Válasz 2014-05-13 01:29:47 #2838

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  J.K.F.

  csendes tag

  válasz weiss #2837 üzenetére

  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.958824

  Hogy 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 hozzászólás Aktív témák