- Xiaomi 13 - felnőni nehéz
- Milyen okostelefont vegyek?
- Samsung Galaxy A36 5G - a középső testvér
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Honor Magic6 Pro - kör közepén számok
- Honor 200 - kétszázért pont jó lenne
- Redmi Note 13 4G
- Yettel topik
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- iPhone topik
Új hozzászólás Aktív témák
-
J.K.F.
csendes tag
Én használtam ilyen vízálló toldót amit említettél, ezt a típust: [Scotchlok UY2]
Elég egyszerű használni: [VIDEO]
Egyetlen hibát lehet vele elkövetni (amit én el is követtem): ha nem elég bátran nyomod bele a narancs színű fejet az eszközbe, akkor kontakthibás lesz a kötés. Nekem pár hónap után jelentkezett a hiba, az ADSL kapcsolat váratlanul szétesett, majd 1-3 Mbps-el állt csak össze. Ha ráhívtam a vonalas telefonra, a hiba MEGJAVULT pár napra, aztán újra előjött.
A megoldás az lett, hogy még néhány tizedmilliméterrel össze kellett préselni az eszközt, úgy, hogy a narancs színű "gomb" teteje teljesen belesimuljon a eszköz tetejébe. Azóta tökéletes, lassan fél éve. Amúgy nagyon jó kis cucc, összepréseléskor kitüremkedik a gél egészen a csövecskék végéig és vízállóan lezárja a kötést. A szerelő korábban csak összesodorta a két kábelt, ez annál csak jobb lehet.
-
J.K.F.
csendes tag
Inkább örülj neki, hogy be tudsz jelentkezni.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Engem több hónapja egy sajnálkozó üzenet fogad ha megpróbálok ügyfélszámmal belépni, hogy saaaaaaaaaajnos pillanatnyilag nem működik nálam a kívánt funkciók elérése (volt erről valami cikk is a neten, nem csak én jártam így és nem tudni mikor oldják meg végre), próbálkozzak telefonon vagy személyesen. Mondjuk a VDSL réme engem úgysem fenyeget, mivel "túl messze lakom a központtól". A "messze" egyébként 830m-t jelent légvonalban, persze nem kizárt, hogy kábelnyomvonalban ez 2-3x-os érték (a csillapítás mindenesetre elég jelentős, 26dB).
-
#3074
J.K.F.
csendes tag
PainKiller13
#3073
J.K.F.
csendes tag
válasz
PainKiller13
#3073
üzenetére
A google szerint Invitel területen a VPI/VCI = 8/32 vagy 8/35.
Esetleg még az is előfordulhat, hogy Annex A-t használnak azon a területen, ekkor Annex B helyett azt kell beállítani a modemben. De szerintem először próbálkozz Annex B-vel és a fenti VPI/VCI párosok valamelyikével.
-
J.K.F.
csendes tag
válasz
ssarosi
#3006
üzenetére
Csak tippelni tudok [ezen leírás 4. pontja alapján], ha már van szinkron de nem megy a PPPoE, akkor:
- ATM beállítások rendben? VPI/VCI: 1/32
- VLAN id rendben? VLAN id: 32 [ZTE leírás 4.3.2 ábrája alapján] -
J.K.F.
csendes tag
válasz
ssarosi
#2988
üzenetére
Akkor most ez ki tudná használni az ISDN sávszélességét is, vagy azt abszolút nem használja?
A [#2737] hozzászólásban szereplő kép alapján azt mondanám hogy nem, ez is a 64-es fölötti vivőket használja, vagyis Annex B-s ("... over ISDN") átvitelt. A VoIP-et szerintem két okból ajánlják: egyrészt árukapcsolás (gondolom szeretnének megszabadulni a régi analóg telefonközpontoktól), másrészt tényleg lehet, hogy a DSLAM-ben nincs beépített splitter (különálló splittereket meg valószínűleg nem akarnak használni) csupán kimazsolázza a VoIP bitjeit az adatfolyamból.
Nagy kár, mert SZERINTEM simán plusz 1-1.5Mbit-et jelentene az Annex A használata VDSL-nél a download sávszélességben. Most komolyan, ki a fene használ még 2014-ben ISDN-t, akit meg kéne védeni attól, hogy esetleg az áthallás egy VDSL érpárról egy icipicit zavarja abban a sávban?
-
J.K.F.
csendes tag
válasz
ssarosi
#2986
üzenetére
Az a fura, hogy a letöltős linkről letöltve mindkét (A/CH és International) firmware-t azoknak nemcsak a nevük egyezik, hanem bitről bitre egyeznek. Persze ettől még lehet eltérés a hardware-ben, amit lekérdezve másként viselkedik az egyiken és másként a másikon. Garmin GPS-nél is volt olyan, hogy ugyanazt a frissítést kellett letölteni 2-3 hasonló típusú vashoz is, de azok másként viselkedtek az egyes hardware-eken (pl. nyilván nem volt barometrikus magasságmérés olyan eszközben, amiben nem volt ilyen szenzor).
A különbség lehet, hogy az lesz, hogy nem tudsz majd "Hungary"-t választani a Regional Settings-ben, csak "Austria" vagy "Switzerland" lesz választható (lásd [ITT], bár ez a 7360-asról szóló leírás). De hogy ennek hol van jelentősége, arra tippelni se nagyon tudok. Pl. gyárilag választható szolgáltatók listájánál vagy a telefonközpont valamilyen ország előhívószámos beállításánál... Majd kiderül, próba szerencse!
-
J.K.F.
csendes tag
válasz
ssarosi
#2982
üzenetére
BIZTOS, hogy nem állítható be rajta az angol nyelv is opcióként?
[Itt] 3 féle firmware verzió tölthető le:
* deutsch: az info fájl szerint ez csak német nyelvű, és bár az info fájl nem ír erről, de a fw. neve alapján pedig csak AnnexB-t tud (csak a FRITZ!Box Fon WLAN 7390 típusra telepíthető)
* deutsch_a-ch: az info fájl szerint ez német, angol, francia, olasz és spanyol nyelvű, Annex A és Annex B (csak a FRITZ!Box Fon WLAN 7390 A/CH típusra telepíthető)
* english: az info fájl szerint ez angol, francia, olasz és spanyol nyelvű, Annex A és Annex B (csak a FRITZ!Box Fon WLAN 7390 International Edition típusra telepíthető)Tehát eszerint ami Annex A-t és B-t is tud egyszerre, az mindenképp tud angolul is.
-
#2938
J.K.F.
csendes tag
SteveBeard
#2934
J.K.F.
csendes tag
válasz
SteveBeard
#2934
üzenetére
Ezen egyébként nem látszik semmi extra, csak az, hogy ez idő alatt viszonylagos nyugalom volt a vonalon. A mérés akkor lett volna érdekes, ha hosszabb ideig áll a net és nem tudsz életet lehelni bele. Annyi látszik még, hogy eddigre (este 20:00-kor) már kikapcsolták az MR4 nemzetiségi adást 1188kHz-en (Marcali és Szolnok adók), ami napközben azt a hatalmas csúcsot okozza a 275-ös vivő környékén.
Remélhetőleg a modemcserével megoldódnak a gondjaid. Ha mégsem, akkor nem modemhiba volt az ok, inkább kábel/kötés.
-
-
#2931
J.K.F.
csendes tag
SteveBeard
#2930
J.K.F.
csendes tag
válasz
SteveBeard
#2930
üzenetére
Vonalas telefonod is van az ADSL mellé? Ha van, akkor szakadáskor az ad búgóhangot vagy néma?
Nálam házon belül volt olyan kötéshiba (amit én követtem el), amitől megszakadt vagy nagyon lelassult a net (1-3Mbps). A vonalas telefon ilyenkor nem adott búgóhangot, ha viszont ráhívtam erre a számra, majd 10-15 másodpercnyi kicsöngés után letettem a hívást a net is és a telefonvonal is megjavult. Egy időre. Végül újranyomtam a hibás kötést és azóta minden szép és jó.
A képen látható 2-3 durva minőségromlás (vagy teljes szakadás?) csak 15-30 másodperces. Azokat Te csináltad (pl. kábel kihúzása a modemből) vagy "magától" történt? Ha a szakadás hosszabb ideig fennáll és pl. a modem újraindítása sem segít, esetleg ki lehetne próbálni egy QLN tesztet az xDSLinfo 1.99beta-val 5 másodperces mintavételt beállítva, és össze lehetne hasonlítani az ott látott QLN grafikont pl az előző képeden látható QLN grafikonnal, hogy nincsenek-e benne ahhoz képest fura eltérések (sok zajcsúcs, vagy egységesen több decibeles eltérés minden vivőn). Ha jól emlékszem ez a QLN teszt csak a dchard-féle szoftverrel működött nálam, a gyárival nem.
-
J.K.F.
csendes tag
Ha nem fogadja el a név/jelszó párost akkor valószínűleg még a gyári firmware van a modemen. A DMT nem tud kommunikálni a gyári firmware-rel (még a helyesen megadott, a gyári fw-ben érvényes név/jelszó párossal sem, ahol a felhasználónév "root", a jelszó pedig "admin") ahhoz fel kell raknod dchard firmware-ét.
Az általam írt [xDSLinfo] ellenben szót ért a gyári fw-rel is (az alapértelmezett név/jelszó párosa is ennek megfelelő) és a dchard-féle fw-rel is (ekkor át kell írni a beállításaiban a jelszót "0000"-ra). Ezzel azonban csak lekérdezni tudod a modemet, illetve órákon keresztül monitorozni tudod, hogyan változik a jel/zaj viszony a vonalon (hasonlóan a DMT-hez), modembeállítások módosítására nem alkalmas.
Ha valamit állítgatni is szeretnél a modemben, ahhoz fel kell raknod a dchard-féle firmware-t, és annak webfelületén tudod ezt megtenni.
-
J.K.F.
csendes tag
válasz
X-ecutor
#2886
üzenetére
Próbáltad másik UTP kábellel is?
A modem és a számítógép közé elvileg "egyenes" UTP kábel kell (az 1,2,3,6-os RJ-45 csatlakozó lábak mindkét oldalon azonos színű ereket fogadnak, ha alulról nézel rá az UTP csatlakozóra, ezt le is tudod ellenőrizni), míg a modem és egy switch közé "keresztkábel" kell. Pontosabban régen az kellett, mert manapság routerek/switchek többsége "auto MDI/MDI-X"-es, vagyis mindegy neki, hogy egyenes vagy keresztkábelt használsz.
Szóval lehet, hogy most keresztkábellel próbálkozol, ami a routernek mindegy (mert ő nem válogatós), de a PC-nek/laptopnak nem.
-
J.K.F.
csendes tag
válasz
AstraCDX
#2863
üzenetére
Nem láttad volna, csak ha mindazt megcsinálod, amit a 2860-as hsz-omban leírtam. Viszont elképzelhető, hogy az se lenne túl jó ötlet, amennyiben dchard-nak igaza van és a router funkcionalitás felélesztése már túl sok lenne a 380T-nek (és a gyenge processzor miatt épp elég szegény "modemnek" [igazából CPE-nek kéne hívni, ha korrektek akarnánk lenni] a bridge-elés is).
-
J.K.F.
csendes tag
válasz
AstraCDX
#2859
üzenetére
Ha a 380T tényleg tudja végződtetni a PPPoE-t, akkor a helyedben a következőképpen járnék el, ha mindenképp el akarom érni a modemet is:
- Modem: végződteti a PPPoE-t, DHCP engedélyezve (mondjuk, 192.168.1.50-192.168.200-ig oszthatna címeket) IP címe: 192.168.1.1, subnet mask 255.255.255.0
- Router: a WAN protokoll mindegy, hogy mire van beállítva, mert ez esetben az egyik LAN portba dugnám a modemet! A DHCP szerver funkcióját letiltanám (!!!) és kézzel 192.168.1.254 LAN címet adnék a routernek (subnet mask 255.255.255.0).Ilyen módon a routert egy LAN switch-csé degradálnánk, ráadásul a 4-ből már csak 3 portja használható. IP címeket a 380T osztana, ő lenne a router az internet felé.
-
J.K.F.
csendes tag
-
J.K.F.
csendes tag
válasz
AstraCDX
#2856
üzenetére
Így már érthető, miért működött neked korábban. Azért működött, mert rosszul állítottad be a routert.
PPPoE-t beállítva a router nagy ívben tojik rá, hogy milyen IP címet kapott az ADSL modemtől, ilyenkor az ő WAN oldali IP címe a PPPoE-n kapott internetjogos IP cím lesz. Így nem tud róla, hogy azon a portján is egy 192.168.1.x-es hálózat található.
Egyébként is nagyon nem volt elegáns megoldása DHCP-s esetben az, hogy egy router két különböző "lábán" (LAN ill. WAN oldal) azonos címtartomány legyen, kész csoda, hogy oda is átdobta a broadcast-okat és rátalált a modemre. Ha egy kicsit szemellenzősebb lett volna a router, akkor azt kellett volna gondolnia, hogy a LAN oldal a 192.168.1.x, bármilyen kérelem, ami ugyanazon a címtartományon belüli eszközt keres a 4 LAN port egyikére mehet csak, a WAN oldalra semmiképp. Ezt sikerült megzavarnod azzal, hogy a WAN oldal ugyanazon címtartományt használta, ezért talált el a modemig az adatcsomag.
Alapvetően kétféleképpen lehet elérni a modemet a router mögött:
- A router programozásával, extra routing bejegyzés beírásával, lásd ezt a német nyelvű cikket: [link]. Ehhez azonban DD-WRT-t kell futtatnia a router-ednek, gyári router firmware-ek nem szoktak ilyet tudni. Elvileg ez az elegánsabb megoldás.
- Kevésbé elegánsabb, viszont nagyon egyszerű megoldás, ha a Router WAN portját bekötöd az egyik LAN portjába és a modemet egy másik LAN portba.
Ezzel persze egyből elvesztesz két LAN portot a négyből (tehát igazából nem 3, hanem már csak két PC-t tudsz bekötni, szemben a fenti ábrával). Persze a DHCP szerver funkciót azonnal tiltsd le a modemen (már most sincs rá szükség, de ebben az esetben egyenesen tilos!), mert nagyon nem lenne szerencsés, hogy hol a router hol meg ő osztogat IP címeket a LAN tartományodból. Arra is kell figyelni, hogy nehogy ugyanaz legyen a modem IP címe (192.168.1.1) mint a routeré, mert az IP cím ütközés is balszerencsét hoz. -
J.K.F.
csendes tag
válasz
csacsa72
#2849
üzenetére
Szerintem azért lehet alacsonyabb az attainable rate mint az aktuákis sebesség, mert azt a 6.0dB-s target SNR margin-ra számolta a modem, és itt már az alá romlott az SNR margin-od. Megfigyelhető, hogy a 6.2dB-s előző mérésednél egy picit magasabb volt ez az érték mint az aktuális sebesség, itt meg egy kicsit alacsonyabb.
-
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
válasz
ssarosi
#2832
üzenetére
Ha nem kérek túl sokat letesztelnéd majd az én programommal is mielőtt 20Mbps-re áttérnél, hogy milyen max. sebességet "jósol" arra a vonalra? Kíváncsi vagyok, mennyire jól/rosszul sikerült a sebességbecslő programrész (ez persze csak akkor derülne ki, ha már átraktak abba a csomagba), mivel a modem saját sebességbecslései meglehetősen optimisták.
A program innen tölthető le (forráskóddal együtt): [xDSLinfo v1.99beta]
Jelenleg valahogy így fest a program:
... a jobb alsó sarokban lévő értékek lennének érdekesek.
-
-
J.K.F.
csendes tag
Én azért még bízom az SNMP-ben...
Nem hinném, hogy az csak vonali irányban menne (ha egyáltalán TUD arrafelé menni), a helyi ethernet felől meg tiltva lenne. Sokkal jobban tartok attól, hogy esetleg nem ismeri VDSL2 MIB-et, hanem csak valami nagyon alap SNMP-t tud: pl. kiolvashatod az InOctets, OutOctets és hasonlóan épületes változókat.
-
J.K.F.
csendes tag
Oké, köszi!
Majd kitalálom, hogyan lehetne a jelenlegi felületen mérés típust választani (teljes /QLN). De ez komoly, hogy a mérés végén sem lesz "up" az link állapota? Akkor mire jó az időintervallum (már azon kívül, hogy utána nem él már a precíz QLN mérés)?
Más: bár nem áll szándékomban plusz munkát csinálni magamnak, de felmerült itt a Speedport W 724V típusú VDSL2 CPE menedzselhetősége. Esetleg megpróbálkozhatom vele, de ahhoz kéne némi infó.
Ha valakinek ilyen van, megnézhetné, hogy:
- Telnet-tel, ssh-val rá lehet jelentkezni az eszközre?
- Ha nem akkor a webfelületére?
- Ha a webfelületen be is tud lépni az illető a megfelelő név/jelszó párossal, akkor be kéne kapcsolni az SNMP menedzselhetőséget.
- Ezután meg kéne vizsgálni, mit lehet róla lekérdezni tőle SNMP-ben. Csak a szokásos "nesze semmi, fogd meg jól" uptime-ot, interfész-státuszt (up/down) és hasonló badarságokat, vagy támogatja a VDSL2 MIB-et is? Ezek SNMP lekérdezéséhez persze kell egy MIB browser is (pl.: [link]), meg a VDSL2 MIB és az a két másik MIB amitől az függ ([VDSL2-LINE-MIB], [VDSL2-LINE-TC-MIB], [HC-PerfHist-TC-MIB]). No meg kitartás, és kísérletező kedv. -
J.K.F.
csendes tag
A Speedport W 724V-hez lehet egyáltalán telnet-tel vagy ssh-val csatlakozni?
Mert ha nem (a netes hozzászólásokból úgy gyanítom, hogy nem), akkor szerintem reménytelen, hogy a DSLstats-al infót nyerj ki belőle. A webfelületére tudsz egyáltalán kapcsolódni és be is tudsz lépni? A doksija szerint ([link]) viszont tud SNMP-t az eszköz (140. oldal a doksiban), így maximum azt tudom elképzelni, hogy ha ismeri az eszköz a VDSL2-LINE-MIB-et ([link]), akkor valahogy SNMP-vel lehetne adatokat kinyerni belőle, az alábbi MIB-ágak biztatónak tűnnek:
-
J.K.F.
csendes tag
Az 1. problémára nem lenne megoldás a Settngs-ben néhány mező, hogy "ezeket a parancsokat hajtsd végre kapcsolódás után"? Valamelyik ADSL progiban láttam ilyesmit. Ez azért lenne praktikus, mert elég egyszer kitölteni és mentené a többi beállítással együtt, így nem kellene minden kapcsolódáskor plusz parancsokkal vacakolni. De ez csak egy ötlet.
A 2-es pontra is van egy kezdemény a Settings-ben, a "Command perfix". Jelenleg itt még csak "adsl" és "adslctl" között lehet választani, de ezt a 3 plusz variációt simán fel lehetne tenni még az étlapra.
-
J.K.F.
csendes tag
Hát ha tényleg van nullánál nagyobb igény VDSL2 verzióra is, akkor megpróbálkozhatom vele, hogy ne dchard-nak kelljen vesződnie az eddig megírt programrészletek kibogozásával.
Ehhez persze tényleg kellenének majd valami minta log-ok, feltéve, hogy VDSL2-nél is ugyanazok a (Broadcom) parancsok használhatóak:
adslctl info --Bits
adslctl info --SNR
adslctl info --Hlog
adslctl info --QLN
adslctl info --show
adslctl info --versionViszont érdekelne dchard véleménye is, hogy mit lehetne még a képernyőre zsúfolni az eddigi "minden egy képernyőn" megoldás jegyében. Itt elsősorban hibaszámlálókra gondolok, pl.:
SFErr
RSCorr
RSUnCorrHEC
OCD
LCD
Bit ErrorsES
SES
UAS
ASBitswap
Vagy az adslctl info --stats negyedórás statisztikái közül:
SF
CRC
LOS
LOF
ESJelenleg ugyanis a program semmi egyéb paramétert nem naplóz, mint ami a képernyőn is látszik. Arra is gondoltam, hogy a "General ADSL info" boxba lehetne egy mini-grafikont tenni melyen a fenti hibaszámlálókból lehetne 1-et ábrázolni (ez egynél több számláló egy grafikonon nem biztos, hogy szerencsés, mert ha az egyik nagyon "elszáll", akkor a skála annyira nagy átfogású lesz, hogy a másik számláló látszólag végig "0" lehet). De ez lehet, hogy már túl pofátlan koppintás lenne a DMT-ről, nem tudom. Esetleg a programablak is lehet kicsit nagyobb, 35-40 pixellel lehet még szélesebb, és akkor még mindig elfér bármilyen 1024x768 vagy afölötti felbontású kijelzőn.
Egy picit már változtattam a legutóbbi publikus béta óta a programon, de az tényleg minimális: a grafikonok feliratai nem "Small fonts", hanem élsimítás nélküli "Tahoma". Ez azonos magasság mellett kicsit szélesebb számjegyeket jelent, ami szerintem sokat dob az olvashatóságon. A "Small fonts"-al ellentétben ráadásul nem viselkedik furán nagyobb felbontású monitorokon sem (vicces volt, hogy 1920x1200-as monitoron a small fonts egy pixellel alacsonyabb lett, és így még olvashatatlanabb).
-
J.K.F.
csendes tag
Majd kipróbálom, mi a helyzet most a vonal megszakadásakor, egyelőre hagyom "járni" még pár napot.
A scrollozhatóság nyilván megoldható lenne, egyszerűen csupán 8x ilyen széles grafikonokat kell legyártani, amit aztán be kell tenni egy 512 pixel széles láthatatlan szegélyű keretbe, majd egy scrollbar használatakor az összes grafikont és feliratot a kívánt irányba jobbra vagy balra léptetni, hogy a látható 512 pixel széles "ablak" területére kerüljön a vizsgálni kívánt rész. Egy másik megoldás az lehetne, hogy a grafikonok továbbra is csupán 512 pixel szélesek, csupán a skála kezdőpontját állítaná a scrollbar, ekkor újra kéne számolni a kijelzett értékeket az új kezdőpontra viszonyítva.
Kérdés, hogy mire kell egyáltalán a PNG fájl, hacsak nem demonstrációs célokra (pl kinyomtatni). Mert ha távsegítség nyújtásához kell, akkor egyszerűbb és célszerűbb a mérést tartalmazó fájlt küldözgetni, az sokkal nagyobb szabadságot ad: így ugyanis tetszőleges időpillanatot lehet vizsgálni a mérési időtartamon belül, nem csak egy kiragadottat.
-
J.K.F.
csendes tag
...amit még valószínű javítani kellene a programon, az a kapcsolat megszakadásának kezelése (mármint a modem és a DSLAM között). Ezt nem nagyon mertem tesztelgetni, nehogy a túlbuzgó DSM miatt a végén még 64kbps legyen a download-om, 16384-es interleaving depth mellett.
De úgy rémlik, hogy mikor egyszer széthúztam a kábelt még a régi firmware-nél, az adatok nem változtak a programomban vagy legalábbis nem eléggé (pl. az "adsl info --show" ilyenkor elég szűkszavú emlékeim szerint és arra nem készültem fel, hogy SEMMILYEN adat nem lesz amit ekkor be lehet emelni a programba - pedig ilyenkor a program General ADSL infó mezőjében illene legalább minden mezőben "-"-t vagy "N/A"-t megjelenítenem).
-
J.K.F.
csendes tag
A VDSL2 4096db tone-jához azért nem árt egy 4K-s monitor, hogy kiférjenek az oszlopok!
Vagy átlagolgatni kell pl 8 tone-onként. A program jelen verziója eléggé 512 tone-ra van kihegyezve és igyekeztem úgy rápakolni az elemeket, hogy akár 1024x768-as monitoron is elférjen minden látnivaló (nem is lehet átméretezni a programablakot se kisebbre, se nagyobbra mint amekkorára belőttem a méretét).A kód viszont nem lett valami letisztult, nem spóroltam pl a globális változókkal, meg az SNR, QLN, ATT mérési adatokat is elég lett volna 4 bájtos "single"-ként rögzíteni és akkor a mentett mérések csaknem fele ekkorák lehetnének (jelenleg 36MB egy 12 órás mérés 15 másodperces mintavétel mellett).
Viszont sajnos nem tudok menni hétfőn tesztelni, mivel 100km-re lakom az egyetemtől.
-
J.K.F.
csendes tag
Üdv!
Felraktam hát az új firmware-t, viszonylag problémamentesen.
A tapasztalatok: sok változás nincs, legalábbis pozitív irányban. Sajnos.
- Egy picit romlott a 64-511. bin-ig szumázott SNR és Bits érték, de nem jelentősen.
- Picit javult az SNR margin, de nem jelentősen.
- Jelentősebb mértékben romlott a kijelzett csillapítás, ez érdekes...
- Az interleaving értéke immár galaktikus mértékű lett (448).A múltkori grafika kiegészítve a most mért értékekkel, amelyeket sárgával jelöltem:
A lekérdező programommal a váltás csaknem zökkenőmentes volt. Két dologgal szívtam csupán. Az egyik, hogy a downstream/upstream aktuális és maximális értéke máshová került a Telnet-es felületen, így üres értékeket észlelt a programom, de átírtam, hogy ezen az új helyén is megtalálja azokat ne csak a régin. A másik pedig, hogy eddig ömlesztve adtam át a szükséges parancsokat a Telnet-nek, de nem ELÉGGÉ ömlesztve. Egyesével, de közvetlenül egymás után elküldtem el mind a 6 parancsot, ez viszont ennél a firmware-nél azt eredményezte, hogy az első parancs végrehajtása közben a táblázat kellős közepén megjelent az utána következő 5 parancs, ami miatt csodálkozva nézem a programban, hogy a 194-es csatorna környékén miért 0 néha az átvihető bitek száma (mivel hogy a "194" és az átvitt bitek száma közé ékelődtek be a kiadott parancsok). Mostantól egyetlen egy karakterláncként adom át mind a 6 parancsot, köztük CR+LF karakterekkel, így ez a hiba megszűnt.
A programot még ma fel is töltöm valahová ahogy javasoltad (természetesen forráskóddal együtt, bár arra nem lehetek túl büszke, nem lett túl "elegáns" a kód), hátha érdekel valakit, vagy hasznát veszi.
Szomorúan tapasztaltam viszont, hogy a SNR táblázat még a korábbinál is ritkábban frissül az új fw-rel: az eddigi 17.5sec helyett immár kb 280sec-re (04:40) növekedett a frissülési gyakoriságuk. Most már ki tudtam próbálni a DMT-t is, ott is úgy vettem észre, hogy kb ilyen periódussal változik csupán az "Overall SNR per Tone fluctuation", tehát valószínűleg ez tényleg így van.
Pozitív meglepetés volt viszont, hogy egynél több telnetet is elviselt a szoftver: korábban ha futott a programom, akkor Putty-al nem tudtam rácsatlakozni még egyszer a modemre.
-
J.K.F.
csendes tag
Pedig én próbáltam viszonylag jól értesültnek tűnni - de azért ne túl jól értesültnek (pedig a végzettségem szerint progmatos volnék és távközlési téren is dolgoztam, és épp modemekkel/routerekkel dolgoztam, igaz inkább SHDSL modemekkel), mert az okostojásokat a legtöbb helyen utálják -, de a maximum, amit sikerült elérnem az a port reset. Az "SNR lock" kifejezést szándékosan nem használtam a velük folytatott kommunikációban, mert ha jól értem ez egy általad kitalált kifejezés a jelenségre, nekik valószínűleg semmit se mondana.
Megpróbáltam összeszedni egy "infografikán" egy-két érdekesnek tűnő dolgot:
Biztos egyébként szerinted, hogy ez "SNR lock" és nem valamilyen másik paraméter elb***ása (a szolgáltatói oldalról persze, mivel én továbbra is a módosítatlan, gyári FW-t futtatom a modemen)?
Azért is gyanítom, hogy esetleg nem az, mivel annak szerintem valahogy úgy kéne kinéznie,mint az a #2539 (lockolt állapot) majd a #2547 (unlockolt állapot) hozzászólásokon látszik. Az ő esetében (főleg, ha a két ábrát két böngészőfülön nyitom meg és kattintgatással váltogatok köztük) gyönyörűen látszik a jelenség: az SNR grafikon szinte hajszálra ugyanaz, de a bit allokációs grafikon jóval alacsonyabb a lock-olt állapotban. Látszik az is (ha jól értelmezem az "SNR lock" meghatározását), hogy ennek oka az lehet, hogy a központ oldal ragaszkodik az hatalmas SNR margin értékhez, ezért jóval kevesebb bitet lehet átvinni ugyanazon (csatornánkénti) SNR értékek mellett. A másik eltérés persze a hatalmas interleaving, de ez csak a hibajavítás megkönnyítése miatt van (amit a Telekom még az SNR lock mellé ad "ajándékba", hogy a szolgáltatás tűzön-vízen át MINDENKÉPPEN működjön), elméletileg nincs sebességcsökkentő szerepe, csak a késleltetést növeli.
Az én esetem viszont valami egészen más, mivel nálam az 1. és a 3. állapot esetén 1%-on belül van nem csak az szummázott SNR grafikon (összes csatorna SNR értéke összeadva), hanem az összes allokált bitek szummája is! Ha pedig egymásra vetíteném az előtte/utána SNR és bit-allokációs grafikonokat (ettől az animgif-től most megkímélném a közönséget), csak milliméteres különbségek lennének láthatóak. Nálam tehát látszólag nem az történt, hogy alacsonyabb lett a bit allokációs grafikon az SNR lock miatt, mint a fent említett áldozatnál.
És éppen ezért nem értem, hogyan lehet az, hogy ha ugyanannyi allokált bitem van utána mint amennyi előtte volt, akkor hogy lehet mégis sokkal kevesebb az átvitt sávszélesség??? Ezért tettem még be az "infografikába" a modem webfelületéből azt a két kis táblázat részletet - nem lehet, hogy valamilyen ottani paraméter miatt csökken a HASZNOS sávszélesség, pl. irreálisan nagy mennyiségű hibajavító bit használata vagy ilyesmi okán?
Előre is köszönök minden ötletet ezzel kapcsolatban, már ha volt valakinek végigolvasnia a fenti kisregényt.
-
J.K.F.
csendes tag
Kösz.
Meg is próbáltam visszaállíttatni az eredeti sebességemet a Telekommal, de pont ugyanakkora sikerrel jártam, mint itt majdnem mindenki: semekkorával.
Szerintük nincs semmilyen korlát beállítva, újraindították a portot is, de hajszálra ugyanazzal a sebességgel állt össze a modem: 8957kbps. Kicsit se gyanús, hogy közben az "Attainable rate" meg 17812kbps
-
J.K.F.
csendes tag
Oké, ezt nagyjából értem is, most már tényleg csak arra lennék kíváncsi, hogy ha ugyanannyi (sőt 1%-kal több) bitet visznek át a vivők összesen (ha szummázom 64 és az 511-es közti vivők által átvitt biteket) mint a kábelhiba előtt, akkor hogy fordulhat elő, hogy akkor a modem által kiírt össz-sebesség radikálisan kisebb lett: 12471kbps helyett csupán 8957kbps.
-
J.K.F.
csendes tag
Kék színnel bekarikázva egy "böfi", a mérés 5:34:24 időpillanatában (tehát a kék pöttyök jelzik az adott időpillanat mérési értékeit):
Ilyenkor persze az SNR grafikonon is látszik egy parányi horpadás, de mivel ott 1 pixel 1dB-t jelez függőlegesen, nem látszik ilyen hangsúlyosan mint ezen az ábrán.
-
J.K.F.
csendes tag
...szóval hogy érthetőbb legyen: az előbbi képen a felső grafikon a 11.5 órányi mérés TELJES szummája (tehát valóban nem ANNYIRA nagy az a beleböffentés a többi csatornához képest sem, a 480. csatorna környéki púp - mint szélsőérték - már alig lóg ki a sorból), az alsó viszont csak az utolsó 2 óra 8 percnyi időszak. A korábbi eredmények az alsó grafikonon már kigördültek balra, itt még nem oldottam meg a vízszintes kicsinyítést, cserébe viszont minden mérés külön látszik átlagolódás okozta torzítások nélkül.
Azért nem a teljes 12 órás végeredményt szórtam be egyébként, mert pár perccel a fenti kép után bejött egy hibás mérés. A telnet kapcsolat során adott intervallumonként (5-15-30-60sec) kiadom a lekérdező parancsokat és figyelem a puffert, hogyan érkeznek be az adatok. Ha legalább 200 millisecundumig nem változik a puffer tartalma, úgy tekintem, hogy minden lekérdezett adat beérkezett. Erre nagy ritkán nem elég ez a 0.2sec, ha a modem épp egy kicsit elfoglaltabb, és ennél hosszabb időre megtorpan az eredmények kiírása. Azóta ezt megemeltem 250millisec-re ill. állíthatóvá is tettem (egészen akár 2 másodpercig).
-
J.K.F.
csendes tag
Öööö, bocs, ezek szerint félreérthetőek a grafikonjaim.
Az 5. grafikonon:
- a piros vonal az mérési időszak abszolút átlaga (minden egyes csatornára külön kiszámolva), hogy láthassam, ehhez képest mennyi volt a kilengés fel-le. Lehetne éppenséggel a mérés indításakori érzékekhez is viszonyítani (erre szolgál az "Initial value" a grafikon fölött), de az félrevezető lehet, ha az induláskor szélsőségesen jó vagy rossz volt a "vétel"
- a kék az aktuális érték (az átlaghoz képest)
- a fehér pedig az abszolút szélsőérték a mérési időszak alatt (az átlaghoz képes le ill. fel).(A 6. grafikonon még dolgozok majd egy kicsit egyelőre az jobbról-balra kigördül, ahogy visszanézem a "videót", vagyis a felvett adatokat és időskálát se írattam még ki, de 1 képpont vízszintesen egy mérési periódus - mostanában 15 sec).
Példa (azóta már átméretezhető lett a grafikon manuálisan, hogy "elférjenek" a szélsőséges adatok is):
Ezen is láthatóak a lefelé mutató "tevepúpok" a 384 ill. 448-as csatornákon, ezek egy picivel kisebbek már itt is mint korábban (igaz, itt felére kicsinyítettem a skálát függőlegesen!) és azóta már mérséklődtek a ehhez képest is (főleg a magasabb frekvenciatartományban). Ez egyébként egy 12 órás mérés 11.5órájának felvétele. A szomszédos szobában a modemtől 1 méterre volt egy kombikazán, arra gyanakodtam, de 2 órára kihúzva azt továbbra is bejött ugyanez a zaj. A 2-3 méterre lévő DECT telefon kihúzása a konnektorból sem változtatott ezen. Viszont a modem messzebb helyezése a faltól és/vagy az utolsó 2 méter Cat5e-re cserélése némi javulást hozott. Az is lehet, hogy ez már a kábelen bejön, semmi köze a saját hálózatomhoz.
Az alatta lévő grafikon 2 óra 8 percet ölel fel, ott a lefelé mutató apró tüskék között 8-9 perc telik el, és olyankor a kék pöttyök (amik az aktuális SNR szintet ábrázolják az átlaghoz képest) is lejjebb ugranak a 384 ill 448 környéki "púpok" közepébe.
De ez a kevésbé fontos része volt az eredeti kérdésemnek, ami jobban érdekel, az a bit-allokációs tábla. Eddig azt hittem, azt mutatja, hogy az egyes csatornákon aktuálisan hány bitet tud átvinni a modem ill. a DSLAM. Ha ez nagyságrendileg ugyanannyi mint korábban, hogy lehet az eredményül kapott sávszélesség sokkal kisebb? Mi lesz a többi bittel? Hibajavításra lefoglalja őket a rendszer, vagy tartaléknak?
-
J.K.F.
csendes tag
Köszi ezt is!
Akkor még a bit-allokációs táblával kapcsolatban lenne egy kérdésem, ha szabad.
Ugyebár azt terveztem, hogy átkérem magam a 20/1Mbps csomagba a 10/0.5-ről, hátha legalább 15Mbps-t elbírna a vonal, de... egyelőre annak is örülnék, ha visszakapnám a 10 megámat.
Két hete elkezdett bezajosodni a vonal, gyanús pattogások voltak az analóg telefonban, illetve a modem is lement 1-4Mbps környékére, vagy sokszor szét is esett napközben. Estére azonban mindig megjavult valamennyire (ha nem is az eredeti sebességre). Be is jelentettem 2 hete pénteken, aztán szombaton a szerelő kicsit bütykölt az utcában lévő rendezőben, meg kérésemre megnézte a házfalon lévő dobozkát is ami eléggé oxidált volt és egyenesbe kötötte a benne lévő kábeleket. Ezután szépen meg is javult a vonal, viszont 8952-8957kbps-re állt be fixen a letöltési sebesség 13dB SNR marginnal (korábban 12471kbps volt). A szerelő mondta, hogy ez majd pár nap múlva visszaáll a rendes sebességre, de sajna nem.Azóta egyszer áramtalanítottam is a modemet (más helyre raktam és Cat5 kábellel kötöttem be a fali aljzatból a lapos kábel helyett, mert gyanús volt hogy a naponta pár órán (sajnos kiszámíthatatlan időközönként) keresztül valami 8-9 percenként "beleböfög" az 1MHz fölötti tartományba, 5-6dB-s SNR csökkenést okozva azokon a frekiken, lásd a #2705-ös hozzászólásban látható 5-6. grafikonon - azóta ez nagyrészt 3-4dB alá csökkent). Érdekes, hogy ezután az SNR margin 13dB körül lement a régen megszokott 6dB-re, miközben a grafikonokon semmi radikális változás nem történt a 13dB-s állapothoz képest.
Sőt - és itt végre feltenném az újabb kérdésemet -, ha összeadom a bit allokációs tábla 64-511 közti "bits" értékeit, csaknem 1%-kal magasabb szumma jön ki, mint amikor még IGAZI 10Mbps-em volt. Akkor ez most hogy is van? Több bitet lehet lehet kódolni az egyes frekvenciákon, de a végeredmény mégis kisebb lett mint régen? Az interleaving értékem időközben olyan magas lett, hogy még a Holdról is látszik: 384 (de hát állítólag csak az interleaving érték változása nem okoz sávszélesség csökkenést, csak a ping lassulását). Ez lenne az a híres/hírhedt SNR lock?
-
J.K.F.
csendes tag
Köszi az információkat!
Jól sejtem, hogy a QLN tábla csak ilyen méréskor frissül, ill. a kapcsolat felépítése előtt/alatt (pl ha szétesik a kapcsolat, kihúzom a vonalat a modemből vagy újraindítom a modemet)? 4 óra hosszan mérve működő kapcsolat mellett (5 másodperces gyakorisággal) még csak meg se rezzent soha a QLN grafikon és ugyanez igaz a csillapítás grafikonra is.
-
J.K.F.
csendes tag
A módosított firmware-t használókhoz lenne olyan kérdésem, hogy abban milyen gyakran frissülnek a DMT Tool-lal is lekérdezhető információk (pl: adslctl info --SNR)?
Az eredeti firmware-hez barkácsolt saját lekérdező/naplózó programocskám tesztelésekor tűnt fel ugyanis, hogy annál hiába kérdezem le 5 másodpercenként az adatokat, az SNR/tone diagram alakja csak 3-4 lekérdezésenként változik, ennek megfelelően pedig az ezeket a változásokat szummázó "Overall SNR/tone fluctuation" grafikonon is csak 3-4 lekérdezésenként (tehát 15-20 másodpercenként) történik változás. Lásd a lenti ábrán, különösen jól látszik a pirossal bekarikázott tüskénél.
Rá is szálltam a témára és leteszteltem, mit történik, ha csak az SNR táblázatot kérdezem le, de másodpercenként (még épp belefért az SNR táblázat lekérése 1 másodpercbe). Az eredmény az lett, hogy 17-18 másodpercenként változtak az adatok, és egy 10 perces vizsgálat alatt szinte századmásodpercre pontosan 17.5sec jött ki "adatfrissülési periódusként". Ha viszont ez így van, akkor nincs is értelme 5 másodpercenként lekérdezni a modemet, a 15 másodperces adatgyűjtés szinte tökéletes: minden 7 mérésből 6 különböző értéket fog tartalmazni, csak 1 ismétlődés lesz.
Érdekelne viszont (hogy visszakanyarodjak az első mondatomhoz), hogy vajon a módosított firmware-ben is csak ilyen ritkán frissülnek a táblázatok (tehát a frissülési gyakoriságra nincs hatással a módosítás), vagy ennél gyakrabban (ne adj' Isten ritkábban).
-
J.K.F.
csendes tag
Sziasztok!
Fontolgatom, hogy esetleg 20/1Mbps (Netmánia M) csomagba kérjem át magam a jelenlegi 10/0.5Mbps-ből (Netmánia S). Légvonalban kb 800 méterre vagyok a központtól, de a kábelnyomvonal ennek többszöröse is lehet, meg hát a kábelezés minősége is kérdéses a környéken.
Ki lehetne valamelyik vonali paraméterből okoskodni, hogy kb. milyen sebesség várható az esetleges áttérés után, vagy ez lehetetlen a sok változó (pl. Telekom központ oldali beállításai) miatt? Az "Attainable speed"-ben valahogy nem nagyon hiszek, gyakorlatilag nem láttam még olyan screenshot-ot, amelynél az aktuális sebesség akár csak 10%-on belül is lett volna ahhoz (na jó, 100-ból ha 1 képen van ilyen - sőt, olyat is láttam már talán, amikor az aktuális sebesség volt a nagyobb érték
).A vonali paraméterek egyébként ilyesmik:
Bocs a kezdetleges felületért, de nem mertem firmware-t cserélni, inkább összedobtam ma az utóbbi két délután egy kis lekérdező programot a módosítatlan firmware-ű DSL-360R T1E-re. Szebb is lehetne (lehet, hogy majd még csiszolgatok rajta), de tőlem ennyire telik, nem vagyok valami gyakorlott programozó.
Vizsgáltam az itthoni kábelezést is, hátha azzal lehetne kicsit tuningolni a vonalon: van vagy 35 méter, több darabból áll. Próbaképp ehelyett egy tized ilyen hosszú, tehát 3.5 méteres fali Cat5e kábellel is bekötöttem a modemet közvetlenül a Telekom házfalon lévő dobozába - vagy 20 éves darab, még csavaros rögzítésűek az erek, a földkábel oldali kábelvégek környéke eléggé oxidált, de azt inkább nem piszkáltam (nehogy letörjön vagy ilyesmi), csak a továbbmenő kábelt kötöttem ki -, de a "nyereség" elenyésző volt: 26.0dB helyett 25.5dB lett a letöltési csillapítás és valami 200kbps-el magasabb Attainable speed.
Az SNR margin a feni képen valamivel jobb a szokásosnál, 6dB szokott lenni, de láttam már 4.3dB-n is.
Ja igen, és az mitől lehet, hogy ha kikapcsolom a modemet majd vissza, akkor az Attainable speed kb 15200kbps-re áll be, míg ha ezután kihúzom a vonalat a modemből és fél perc múlva visszadugom, akkor 17700kbps-re? Nagyjából minden más paraméter ugyanaz marad (legalábbis a modem gyári webfelületén - amikor ezt próbálgattam, még nem volt kész a fenti programocska, amivel a grafikonokat is össze tudtam volna hasonlíani), csak az elmélet max sebesség nő meg.
-
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] ).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- ThinkPad P16 Gen1 16" FHD+ IPS i9-12950HX RTX A3000 32GB 1TB NVMe ujjlolv gar
- TUF F15 FX506HC 15.6" FHD IPS i5-11400H RTX 3050 16GB 512GB NVMe magyar vbill gar
- Precision 7670 27% 16" FHD+ IPS i7-12850HX RTX A1000 32GB 1TB NVMe IR kam gar
- AKCIÓ! GAMER PC: Új RYZEN 5 4500-5600X +RTX 3060/3070/3080 +Új 16-64GB DDR4! GAR/SZÁMLA! 50 FÉLE HÁZ
- UHH! HP EliteBook 840 G8 Fémházas Laptop 14" -45% i5-1145G7 4Mag 32/512 FHD IPS Intel Iris Xe Magyar
- AKCIÓ! Gigabyte H610M i5 12400F 32GB DDR4 512GB SSD RTX 3060Ti 8GB Rampage SHIVA Be Quiet! 730W
- AKCIÓ! Apple Mac Studio M1 MAX 2022 32GB 512GB számítógép garanciával, hibátlan működéssel
- Bomba ár! Lenovo IdeaPad 330S-15IKB - i5-8G I 8GB I 256SSD I 15,6" FHD I HDMI I Cam I W11 I Gari!
- ÁRGARANCIA!Épített KomPhone i5 13400F 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- Dell USB-C dokkolók: (K20A) WD19/ WD19S/ WD19DC + 130W, 180W, 240W töltők
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest