Látod, erre nem is gondoltam

I did nothing, the pavement was his enemy!

Köszi de kicsit többet kellett tenni a reset gomb megnyomásánál.

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.

[ Szerkesztve ]

Sziasztok!

Tanácsot kérnék, hogy egy Dlink DSR-360R modem elbír-e egy 20/1 -es adsl internettel. A szolgáltató Btel T-s vonalon. Nemrég kaptam meg a vonalat előtte egy 5M/512k vonal volt azt szépen kiszolgálta, de most a letöltésnél nincs csak 15Mbit a feltöltés hozza az 1Mbit-et
Elvileg a szolgáltató szerint nálam elérhető a 20Mbit az ő mérésük alapján.
Szakadások, hibák nincsenek, torrent is megy és bírja. (kb 2 hét.)
Még nem volt diagnosztika csak jó pár speedtest tudom nem elég, de először megkérdezem, hogy bírja-e, ha igen akkor mókolok vele ha nem akkor váltanék egy gyorsabb modemre.

Segítséget előre is köszönöm!!

A hálózat építést csak elkezdeni lehet, befejezni nem.... Eredetije a HUP-on!! Onnan kölcsönöztem!!

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

A problémának nincs köze a módosított fw-hez, mivel a driver és vele együtt a broadcom adslctl user space progi binárisa is eredeti, nincs hozzájuk forrás. Az egyetlen dolog amivel jobb felbontást lehet elérni az a zajvizsgáló funkció, de azt csak offline módban tudod használni, tehát ha elindítod, nem lesz DSL kapcsolat a mérés erejéig, és ott is csak 17 sec-enként frissül, ellenben magának a megjelenített mérésnek a felbontása már szimbólum sebességű. A zajvizsgálatot az

adslctl qlnmntr --start 60

paranccsal tudod elindítani, ilyenkor 60 másodpercig fut a mérés offline módban, és a QLN tábla lekérdezésével láthatod az eredményt. Kvázi spektrumanalizátort csinál a modemből. Épp most fejezem be a várhatóan utolsó FW verziót, ami ezt a mérést is tartalmazni fogja, így a DMT-re a továbbiakban nem lesz szükség.

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

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.

[ Szerkesztve ]

A QLN, vagy parasztosan magyarra fordítva "csendes vonali zaj" mérés akkor történik, amikor a vonal "csendes", vagyis nincs rajta aktív ADSL kapcsolat. Normális körülmények között a trainelés során 1-3 másodpercig mérik a modemek a spektrumot és azt látod a QLN táblában. Ellenben rá lehet kényszeríteni a modemet, hogy ezt egy meghatározott ideig - akár több óráig - csinálja. Ilyenkor változnak a QLN tábla értékei, már ha van változás a vonalat érő zajban.

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

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?

Olyan nagy "beleböfögés" azért nincs. A probléma az hogy nem látom a zaj nagyságát, nem átlagot, hanem abszolút minimumot/maximumot kéne mérned. A jó időszakok adatai elhúzzák a mérési eredményt, mi nem erre vagyunk kíváncsiak.

A zaj forrását kéne megállapítani, és amennyire lehet eltűntetni.

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

Öööö, 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?

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

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.

" Eddig azt hittem, azt mutatja, hogy az egyes csatornákon aktuálisan hány bitet tud átvinni a modem ill. a DSLAM."

Nem. A bitallokációs tábla azt mutatja, hogy éppen hány bitet visznek (és nem vihetnek) át a vivők.

A vivőn átvihető maximális elméleti kapacitást úgy kapod meg, hogy a vivőn mért SNR-t elosztod hárommal, majd szigorúan lefelé kerekítesz. Ezt ugye zajtartalék nélkül kell érteni. Ha ebből kivonod a vivőhöz tartozó bitallokációs táblában lévő értéket és visszaszorzod 3-mal, akkor megkapod az adott vivőre vonatkozó aktuális zajtartalékot.

Példa: a vivőn 50-es SNR és 11 kódolt bit van:

50 / 3 = 16,66 --> 16

16 - 11 = 5 --> 5 x 3 = 15
tehát 50-es SNR és 11 kódolt bit mellett a vivőn 15dB tartalék van. A példa persze csal, hiszen lehet akármekkora az SNR, 15bitnél nem kódolható több adat egy szimbólumban. De azt hiszem a lényeget érted.

Az SNR Margin amit a modem kiír egy aggregált és átlagolt érték az összes DS és US vivőre, azonban jó néha látni, hogy ez hogyan oszlik el. A szinkronizálás után nyilván arányos, de a különböző helyeken felbukkanó zajokkal ez változhat.

Nálad nincs egetrengető zaj. Nem mondom, hogy szép, de ez a pár dB változás mondhatni normális. Ha már átnézted a lakás hálózatot, akkor a zaj kívülről jön, nem tudsz vele mit kezdeni.

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

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.

Egyértelmű SNR lock. Az elmúlt hónapokban sikerült kiismerni a DSM által használt profilsebességeket, ez egyértelműen a DSM által kiszabott korlát eredménye. Ezért van, hogy az SNR margin csökkentésével sem nő a sebesség.

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

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

Mondjuk ha letagadják az hazugság. Emiatt bőven lehetne az NMHH-nál vagy a GVH-nál feljelentést tenni. Szerintem ha voltak is korábban ilyenek azok azért pattantak le, mert nem szakember fogalmazta meg a panaszt amiből egyértelműen látszik, hogy pontosan értjük a dolog működését így nem rázhatnak le egy ilyen kamu szöveggel, hogy nincs semmilyen korlát.

Én már többször mondtam, hogy szívesen átnézek és javítok, támogatok bármilyen beadványt, de mivel nekem nincs ilyen szolgáltatásom, így én feljelentést tenni nem tudok.

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

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.

[ Szerkesztve ]

Valóban létezik olyan beállítás amivel 10dB target margin és 20megás profil mellett tökéletes vonalon is csak 8mega jön ki, csakhogy itt a bitallokációs tábla is "összeesik", akárcsak az "SNR lock"-os eseteknél.

A kifejezést valóban én találtam ki, mivel ez írja le a lehető legjobban a jelenséget.

Ezt a DSM nevű rendszer csinálja, rosszul. És ráadásul nem is a magas tagret marginhoz "ragaszkodik" ahoygy írtad, ez már csak következmény de nem az ok.

Az oka az "SNR lock"-nál a mgas marginnak az, hogy a DSLAM-ben a porton fix sebesség limitet is be lehet adni, ezzel kényszerítik ki, hogy soha ne léphesd túl a sebességet amiért fizetsz. Namost ha egy vonal elbír 15megát, de én 10-re korlátozom, akkor az e fölött maradó minden bit tartalék lesz és növeli az SNR margin-t.

Lehet hogy az új Huawei DSLAM-ek valamit nem jól csinálnak és ez a furcsa helyzet áll elő?

Legyél már olyan jó és frissíts az általam írt firmware-re amiben lényegesen újabb BCM driverek vannak, nézd meg hogy azzal is csinálja-e. Lehet hogy a gyári szoftver szar. Eleve egy raklappal több paraméter érhető el, és ugyanúgy működni fog a házilag írt progid is, amit mellesleg közzétehetnél. A két FW parancs-kompatibilis.

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

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

üdv
az új fw verziód mikor lesz elérhető?

Ide töltöttem fel a DLink DSL-360R T1E-hez írt monitorozó programomat: ADSLinfo.zip

A forrást külön köszönöm, így könnyen lehet majd módosítani VDSL2-höz is. Ha gondolod tudok küldeni logokat róla és pikk pakk meg lehet írni a támogatást. Ugyanúgy néz ki mint ez, csak nem 512 elemű egy lekérdezés, hanem 4096. Meg a csillapításokat bandonként értelmezi, de ez semmi.

A mérések gyakoriságát le tudom tesztelni laborban, de nincs valami sok időm. Ha akarsz, gyere be hétfőn az egyetemre és szórakozhatsz a mérőkörrel, és nézegetheted milyen gyorsan jelenik meg a becsatolt zaj. Kipróbálhatod több FW verzióval is.

Dchard

[ Szerkesztve ]

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

hamarosan

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

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.

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

Na ez az amit nem érdemes csinálni. Sokkal jobb megoldás scrollozni és megtartani az összes vivőt. Én így csinálom. Az átlagolás elkenhet furcsa hibákat és érdekes jelenségeket, amik például csak 1-1 vivőt érintenek. Csak azt kell megoldani, hogy a képernyőre így egyben ki nem férő adatokat a progiból el lehessen menteni egy PNG-be.

A vivők egyébként kapcsolat bontás esetén is adnak vissza értéket:

a bit és SNR 0-t, a QLN a következő sikeres újraszinkronizálásig az előző mérést tartalmazza, a Hlog szintén, meg az eleve nem változik. De ennél egyszerűbb ha az adslctl info --show parancsból szűrsz a kapcsolat állapotára és csak azoknak a lekérdezéseknek az adatait veszed figyelembe, ahol a kapcsolat állapota "showtime", ez jelenti ADSL-nél a connected vagy operational állapotot. Persze a QLN méréshez ezen majd változtatni kell, hiszen ott nem lesz showtime mód, de csak a QLN táblát kell pollingolni és a progi amúgy is tudni fogja, hogy most éppen QLN mérés van, hiszen onnan indítod el

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

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.

[ Szerkesztve ]

"lehet majd módosítani VDSL2-höz is"

Már várjuk! Addig is köszönjük a sok hasznos infot!!

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 --version

Viszont é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
RSUnCorr

HEC
OCD
LCD
Bit Errors

ES
SES
UAS
AS

Bitswap

Vagy az adslctl info --stats negyedórás statisztikái közül:

SF
CRC
LOS
LOF
ES

Jelenleg 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).

Küldök neked ilyet holnap.

Amivel mindenképpen érdemes lehet még kiegészíteni, az a diag megkezdése előtti saját parancs futtatási lehetőség. A broadcom parancsok nagy része szintaktikailag nagyon hasonló vagy ugyanaz, csak annyiban térnek el, hogy:

1. Van olyan modem, ahol ki kell adni az "sh" vagy más parancsokat, hogy rendes temrinált kapjon az ember.

2. Sok helyen más-más neve van a binárisnak: "adslctl" vagy "xdslctl" vagy "xdslcmd" vagy "adslcmd". Ezek mind szintaktikailag azonos kimenetet adnak, csak a nevük más.

Így az alkalmazásod szinte minden BCM képes modemmel kompatibilis lehet.

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

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.

VDSL2 monitorozásához egyébként ajánlom a DSLstats alkalmazást, vagy akár ötletforrásként is a saját programhoz. (forráskód is fent van tudtommal)

[ Szerkesztve ]

Igen, most, hogy nézem: ebben láttam az extra parancsok lehetőségét kapcsolódás után a "Special login" beállítás-fülön.

"VDSL2 monitorozásához egyébként ajánlom a DSLstats alkalmazást"

Próbáltam,de sajnos a Speedport W 724V-el nem működik.Ha jól láttam nem
támogatja ezt a tipust.

Igaz, az eszemben sem volt, hogy mostanában már ilyet osztogatnak, nekem még szerencsére a ZTE van, azzal működik.
Sajnos nem tudom mi ketyeg a Speedport burkolata alatt, lehet hogy működőképessé lehetne tenni azzal is, bár sok esélyt nem látok rá.

Ha már itt vagyok, kérdezném hogy késő délután, este környékén mi okozhat ekkora zajt? Sok IPTV-s?

Délelőtt

Este

Dehogy az IPTV-sek...

Sokkal inkább hűtő vagy mosógép vagy trafó a telefonkábel közelében.

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

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:

Üdv!
Egy kis problémám adódott a hálózatommal,és ennek a megoldásához kérnék segítséget,véleményt.
Kb két hete kezdődött csak úgy hip-hop eltünt a net.Most megint megtörtént.Amit csináltam.Mivel úgy láttam,hogy a modemen nem a megszokott módon villognak a ledek ezért gondoltam egy ki-be kapcs helyre hozza.Ami most pirosan villog bal oldalt az nem csinált semmit a másik két zöld folyamatosan világított.Ez így is volt elő alkalommal egyszer kellett újra indítani. most kétszer.Azt szeretném kérdezni,hogy tudnám pontosan kiszűrni ,hogy hol a hiba(szúrő,modem ,router,vonal,stb).
Várom a segítséget.

A dchard-féle fw van rajta.Fekete D-link 360R a modem.

Most megint megtörtént. Ami most pirosan villog bal oldalt az nem csinált semmit a másik két zöld folyamatosan világított.

Nem tudom, hogy van-e köze a problémádhoz, de ma este nekem is egyszer ez volt. Szinkronizálva volt a modem a központtal, de betárcsázni már nem lehetett. ( = piros led ugye nem villog mert nincs kapcsolat)

[ Szerkesztve ]

Pénteken elküldöm neked a logokat a ZTE-ből amiket ígértem.

Egyetlen dolgot kéne még implementálni, a QLN monitor funkciót:

ha kiadod az "xdslctl qlnmntr --time 3600 --freq 4000" parancsot, a modem QLN teszt módba kapcsol egy óra erejéig másodpercenként 4000-szer vesz mintát a teljes spektrumból (ez a DSL szimbólumsebessége). Ilyenkor elég csak a QLN táblát pollingolni, valószínűleg lényegesen gyorsabban látszódnak majd a változások.

Ilyenkor a modem offline állapotba kerül, ebből az xdslctl connection --up paranccsal lehet kivenni, a mérés végén sem vált vissza magától!

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

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.

Mivel az új Speedport és a ZTE 931 lesznek a két hosszú távon velünk maradó eszközök, így megéri ebbe erőforrást ölni. Én többször is kértem, hogy ajánljanak fel ilyen eszközt, anélkül nem lehet hozzá támogatást írni. Nekem van ZTE 931-em, amihez egyszerűen lehet telnetet varázsolni, de a Speedportot mindenképpen kezelésbe kell venni, azon le van tiltva minden értelmes felület. AZ SNMP is max a DSL interfészen van egnedélyezve...

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

Na dobj egy mailt és küldöm a logot a ZTE 931-ből.

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

Köszi! Az email címedet sajna nem találtam, ezért írtam privát üzenetet helyette.

Speedport W 724V-t kaptam új belépőként.

És hajlandó vagy kölcsön adni? Vagy neked már nem kell?

Dchard

A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]

Nekem ezen van most az élő netem. 20/1 csomaggal (Zalaegerszeg)
Távoli asztalos hozzáférést tudok biztosítani egy win8 géphez amiről el tudod érni speedport v-dsl modemet.
Tesztelésben is szívesen segítek.
VLaci