Keresés: - [Re:] Új firmware D-Link ADSL modemekhez

Legfrissebb anyagok

Mobilarena témák

PROHARDVER! témák

IT café témák

GAMEPOD témák

LOGOUT témák

Keresés

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

#2278 re_mod tag

Új Válasz 2013-03-21 11:44:07 #2278
Ú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

re_mod

tag

Mondjuk nem rossz hogy hadoválnak össze vissza mindennel hogy miért szakad a vonal, ahelyett hogy megmondanák az igazat túráztatják a szakavatottabb felhasználókat mindenféle modem buherálással stb. közben pedig más miatt szakad a pppoe.
#2254 re_mod tag Kris87 #2253

Új Válasz 2013-03-05 11:44:09 #2254
Ú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

re_mod

tag

válasz Kris87 #2253 üzenetére

A Bandwith Test modul benne van a MikroTik-ban és azzal max. 2-3 perc alatt dobja tuttira 100 TCP kapcsolattal és a random data legyen bekapcsolva csak ehhez kell egy szerver tehát egy másik gép ahová küldi ugyanilyen MikroTikkal.
Most a router nélkül próbáltam direktbe ilyenkor valami nagyobb torrent file amit kb. 1000-nél több peer van is kiakasztja de nem olyan hamar de ha jó nagy méretű olyan 10GB vagy nagyobb nem megy végig a letöltés.
Próbáltam már az összes ppp paraméterrel játszani LCP kiterjesztések letiltása de akkor sem jó.
Viszont érdekes hogy több helyről olvastam hogy általában 4. echo request fail után dob, viszont nálam az első után lecsatlakozik. Valahogy nem vágom már tényleg mi lehet mert a logban olyan minta a received echo request után bontja le a modem.
Több tucat féle eszköz variációval próbáltam de az a baj hogy így nem tudok mivel védekezni a szolgáltatónál mert olyan mintha a modem oldaláról bontaná. Nem tudom ezt hogy találták ki de nagyon ügyes így nem lehet anyázni.
Talán annyi megoldás volt régebben hogy a lehúzott TrendChippes TP-Link 8816A modemekkel valamit játszik az mss csomagokkal és ott nem dobálta csak annyira szarul kezelte a csomagokat hogy érzésre nem volt olyan jó.
A CfosSpeed is jó ha direktbe megyek fel legalábbis tavaly még jó volt mikor legutoljára belemélyedtem ebbe.
#2244 re_mod tag Kris87 #2243

Új Válasz 2013-03-04 08:29:57 #2244
Ú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

re_mod

tag

válasz Kris87 #2243 üzenetére

A bandwith test-el a mikrotik-ban jól reprodukálható a hiba 100 TCP kapcsolattal kb. 2-3 perc alatt dobja a linket. Valószínűnek tartom hogy anno egy frissítés által álltak át erre a paraméterekre lehet mikor kezdtek bejönni az iptv-s csomagok. Más kérdés hogy sok helyen lehet emiatt szétb*szták az addig jól működő hálózatot.
Szerintem ha a rendszer lenne túlterhelve akkor vagy a pingek vagy a sávszélesség lenne nagyobb ill. kisebb.
Most odáig jutottam hogy gyakorlatilag bármennyi mega sávszélességgel reprodukálható a szakadás megfelelő szál esetén akár 25-nál is látni lehet ugyan nem dobja el de ilyen mpls szinkronizáló csomagok jelennek meg amik a szakadás előtt szoktak mikor nagyobb a terhelés.
Az lehet a sejtésem hogy ez nem hiba hanem valami oknál fogva néhány helyen vagy lehet máshol is csak nem veszik észre sokan router mögül így van bekonfigurálva a rendszer.
Sajnos a Telekomnál ezek a régi sunyi beidegződések úgy látszik nem változtak ahelyett hogy elismernék hogy ok ez van úgy tesznek mintha te lennél a hülye.
#2242 re_mod tag pszichiater #2241

Új Válasz 2013-03-03 20:49:50 #2242
Ú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

re_mod

tag

válasz pszichiater #2241 üzenetére

Nem tudom már szerkeszteni de nem akartam direkt ilyen hosszúra....
#2239 re_mod tag

Új Válasz 2013-03-03 18:30:58 #2239
Ú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

re_mod

tag

Üdv.!
ADSL PPPOE kapcsolatnál lehetséges e az LCP Request csomagok idő intervallum módosítása vagy csak a központi oldalról lehet vele változtatni?
Sajnos arra a következtetésre jutottam hogy azért szakad meg a DSL kapcsolatom terhelés alatt mivel olyankor kifutnak az lcp echo request csomagok a megadott time interval értéken. Kb. 3 éve jelentkezett először a probléma amit számtalanszor jelentettem már a T-Home felé de mindannyiszor az lett a vége hogy szerintük semmi baja a vonalnak fizikailag.
Próbáltam már a módosított firm. modemmel is de nem a vonali paraméterekkel van a baj amit már itt is kitárgyaltunk anno. Most egy komolyabb routerrel egy Mikrotik RB750GL routerrel és a Mikrotik Syslog Daemon programmal a logokból ez látszik.
A Winbox-ban a Bandwith Test modult modulnál próbáltam 100 TCP kapcsolattal és rendszerint lefekszik a pppoe kapcsolat kb. 1-2 perc alatt de 25 szálnál is. Arra jutottam hogy nem sávszélesség és szál függő a dolog mert a logban az látszik utoljára hogy mikor elküldi az lcp echo csomagot jön a timeout és megszakítja majd újra tárcsáz.
Na most nem tudom de a szolgáltatónak ezt hiába mondanám így el mert legutóbb is mindenáron a fizikai munkásokkal akartá megoldani a hibát holott a kutya nem ott van elásva.
Annyira nem értek a pppoe kapcsolatok lélektanához hogy ezért merült fel a kérdés hogy ezt az LCP dolgot nem lehet-e modem oldalról valahogy befolyásolni. Ill. ha nem lehet lehet-e bármit tenni vagy mi van ilyenkor esetleg túlterhelt lokálisan a hálózat vagy lövésem sincs, csak azt nem tudom hogy nem tudják vagy nem akarják a szolgáltató oldaláról érdemben foglalkozni a dologgal.
És sajnos az még a gond hogy legutoljára azzal rázott le hogy az én oldalamról szakad meg a pppoe kapcsolat mivel tényleg a log szerint is nálam van a labda. Konkrétan ez van a logban ilyenkor:
pppoe,ppp,debug,packet pppoe-out1: rcvd LCP TermReq id=0x27 in 3-Mar 17:55:33.29 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: LCP closed in 3-Mar 17:55:33.30 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: CCP lowerdown in 3-Mar 17:55:33.31 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: BCP lowerdown in 3-Mar 17:55:33.32 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: BCP down event in starting state in 3-Mar 17:55:33.32 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: IPCP lowerdown in 3-Mar 17:55:33.34 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: IPCP closed in 3-Mar 17:55:33.35 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: IPV6CP lowerdown in 3-Mar 17:55:33.36 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: IPV6CP down event in starting state in 3-Mar 17:55:33.39 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: MPLSCP lowerdown in 3-Mar 17:55:33.39 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: MPLSCP down event in starting state in 3-Mar 17:55:33.39 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: sent LCP TermAck id=0x27 in 3-Mar 17:55:33.39 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: LCP lowerdown in 3-Mar 17:55:33.40 from 192.168.88.1
pppoe,ppp,info pppoe-out1: terminating... in 3-Mar 17:55:33.40 from 192.168.88.1
pppoe,debug,packet ether1: sent PADT to 00:00:00:00:00:00 in 3-Mar 17:55:33.40 from 192.168.88.1
pppoe,debug,packet session-id=0x3f63 in 3-Mar 17:55:33.40 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: LCP lowerdown in 3-Mar 17:55:33.50 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: LCP down event in starting state in 3-Mar 17:55:33.57 from 192.168.88.1
pppoe,ppp,info pppoe-out1: disconnected in 3-Mar 17:55:33.57 from 192.168.88.1
pppoe,ppp,info pppoe-out1: initializing... in 3-Mar 17:55:33.57 from 192.168.88.1
pppoe,ppp,info pppoe-out1: dialing... in 3-Mar 17:55:33.70 from 192.168.88.1
pppoe,debug,packet ether1: sent PADI to FFFFFFF in 3-Mar 17:55:33.77 from 192.168.88.1
pppoe,debug,packet session-id=0x0000 in 3-Mar 17:55:33.77 from 192.168.88.1
pppoe,debug,packet host-uniq=0xc in 3-Mar 17:55:33.77 from 192.168.88.1
pppoe,debug,packet service-name= in 3-Mar 17:55:33.77 from 192.168.88.1
pppoe,debug,packet ether1: rcvd PADO from 00:30:88:1A:20:4F in 3-Mar 17:55:34.16 from 192.168.88.1
pppoe,debug,packet session-id=0x0000 in 3-Mar 17:55:34.18 from 192.168.88.1
pppoe,debug,packet host-uniq=0xc in 3-Mar 17:55:34.19 from 192.168.88.1
pppoe,debug,packet ac-name=adsl in 3-Mar 17:55:34.20 from 192.168.88.1
pppoe,debug,packet ac-cookie=a9 45 e0 7b 47 7e b2 bf 4d 00 77 ad ff fc 82 0d in 3-Mar 17:55:34.20 from 192.168.88.1
pppoe,debug,packet service-name= in 3-Mar 17:55:34.21 from 192.168.88.1
pppoe,debug,packet ether1: sent PADR to 00:30:88:1A:20:4F in 3-Mar 17:55:34.22 from 192.168.88.1
pppoe,debug,packet session-id=0x0000 in 3-Mar 17:55:34.22 from 192.168.88.1
pppoe,debug,packet host-uniq=0xd in 3-Mar 17:55:34.22 from 192.168.88.1
pppoe,debug,packet service-name= in 3-Mar 17:55:34.22 from 192.168.88.1
pppoe,debug,packet ac-cookie=a9 45 e0 7b 47 7e b2 bf 4d 00 77 ad ff fc 82 0d in 3-Mar 17:55:34.22 from 192.168.88.1
pppoe,debug,packet ether1: sent PADR to 00:30:88:1A:20:4F in 3-Mar 17:55:35.23 from 192.168.88.1
pppoe,debug,packet session-id=0x0000 in 3-Mar 17:55:35.26 from 192.168.88.1
pppoe,debug,packet host-uniq=0xd in 3-Mar 17:55:35.32 from 192.168.88.1
pppoe,debug,packet service-name= in 3-Mar 17:55:35.32 from 192.168.88.1
pppoe,debug,packet ac-cookie=a9 45 e0 7b 47 7e b2 bf 4d 00 77 ad ff fc 82 0d in 3-Mar 17:55:35.32 from 192.168.88.1
pppoe,debug,packet ether1: sent PADR to 00:30:88:1A:20:4F in 3-Mar 17:55:36.36 from 192.168.88.1
pppoe,debug,packet session-id=0x0000 in 3-Mar 17:55:36.36 from 192.168.88.1
pppoe,debug,packet host-uniq=0xd in 3-Mar 17:55:36.36 from 192.168.88.1
pppoe,debug,packet service-name= in 3-Mar 17:55:36.36 from 192.168.88.1
pppoe,debug,packet ac-cookie=a9 45 e0 7b 47 7e b2 bf 4d 00 77 ad ff fc 82 0d in 3-Mar 17:55:36.36 from 192.168.88.1
pppoe,debug,packet ether1: rcvd PADS from 00:30:88:1A:20:4F in 3-Mar 17:55:36.46 from 192.168.88.1
pppoe,debug,packet session-id=0x4ee3 in 3-Mar 17:55:36.48 from 192.168.88.1
pppoe,debug,packet host-uniq=0xd in 3-Mar 17:55:36.49 from 192.168.88.1
pppoe,debug,packet service-name= in 3-Mar 17:55:36.49 from 192.168.88.1
pppoe,debug,packet ac-name=adsl in 3-Mar 17:55:36.50 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: LCP lowerup in 3-Mar 17:55:36.53 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: sent LCP ConfReq id=0x9 in 3-Mar 17:55:36.54 from 192.168.88.1
pppoe,ppp,debug,packet <mru 1492> in 3-Mar 17:55:36.58 from 192.168.88.1
pppoe,ppp,debug,packet <magic 0x4ac48f3d> in 3-Mar 17:55:36.58 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: LCP open in 3-Mar 17:55:36.58 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: rcvd LCP ConfReq id=0x1c in 3-Mar 17:55:36.60 from 192.168.88.1
pppoe,ppp,debug,packet <mru 1492> in 3-Mar 17:55:36.61 from 192.168.88.1
pppoe,ppp,debug,packet <magic 0x51bc8c5b> in 3-Mar 17:55:36.61 from 192.168.88.1
pppoe,ppp,debug,packet <auth pap> in 3-Mar 17:55:36.61 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: sent LCP ConfAck id=0x1c in 3-Mar 17:55:36.61 from 192.168.88.1
pppoe,ppp,debug,packet <mru 1492> in 3-Mar 17:55:36.61 from 192.168.88.1
pppoe,ppp,debug,packet <magic 0x51bc8c5b> in 3-Mar 17:55:36.61 from 192.168.88.1
pppoe,ppp,debug,packet <auth pap> in 3-Mar 17:55:36.62 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: rcvd LCP ConfAck id=0x9 in 3-Mar 17:55:36.62 from 192.168.88.1
pppoe,ppp,debug,packet <mru 1492> in 3-Mar 17:55:36.65 from 192.168.88.1
pppoe,ppp,debug,packet <magic 0x4ac48f3d> in 3-Mar 17:55:36.67 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: LCP opened in 3-Mar 17:55:36.68 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: sent PAP AuthReq id=0x8 in 3-Mar 17:55:36.71 from 192.168.88.1
pppoe,ppp,debug,packet <user ****************> in 3-Mar 17:55:36.81 from 192.168.88.1
pppoe,ppp,debug,packet <password ************> in 3-Mar 17:55:36.81 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: rcvd PAP AuthAck id=0x8 in 3-Mar 17:55:36.90 from 192.168.88.1
pppoe,ppp,debug,packet in 3-Mar 17:55:36.90 from 192.168.88.1
pppoe,ppp,info pppoe-out1: authenticated in 3-Mar 17:55:36.91 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: IPCP lowerup in 3-Mar 17:55:36.91 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: sent IPCP ConfReq id=0x10 in 3-Mar 17:55:36.91 from 192.168.88.1
pppoe,ppp,debug,packet <addr 0.0.0.0> in 3-Mar 17:55:36.91 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: IPCP open in 3-Mar 17:55:36.91 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: IPV6CP open in 3-Mar 17:55:36.91 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: MPLSCP lowerup in 3-Mar 17:55:36.92 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: sent MPLSCP ConfReq id=0x1e in 3-Mar 17:55:36.92 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: MPLSCP open in 3-Mar 17:55:36.92 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: BCP open in 3-Mar 17:55:36.92 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: CCP lowerup in 3-Mar 17:55:36.92 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: sent CCP ConfReq id=0x1 in 3-Mar 17:55:36.93 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: CCP open in 3-Mar 17:55:36.93 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: rcvd IPCP ConfReq id=0x4d in 3-Mar 17:55:36.93 from 192.168.88.1
pppoe,ppp,debug,packet <addr 145.236.238.87> in 3-Mar 17:55:36.93 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: sent IPCP ConfAck id=0x4d in 3-Mar 17:55:36.94 from 192.168.88.1
pppoe,ppp,debug,packet <addr 145.236.238.87> in 3-Mar 17:55:36.94 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: rcvd IPCP ConfNak id=0x10 in 3-Mar 17:55:36.94 from 192.168.88.1
pppoe,ppp,debug,packet <addr 78.92.225.101> in 3-Mar 17:55:36.94 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: sent IPCP ConfReq id=0x11 in 3-Mar 17:55:36.96 from 192.168.88.1
pppoe,ppp,debug,packet <addr 78.92.225.101> in 3-Mar 17:55:36.96 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: rcvd LCP ProtRej id=0x1d in 3-Mar 17:55:36.96 from 192.168.88.1
pppoe,ppp,debug,packet 80 fd 01 01 00 04 in 3-Mar 17:55:36.96 from 192.168.88.1
pppoe,ppp,debug,packet pppoe-out1: rcvd IPCP ConfAck id=0x11 in 3-Mar 17:55:36.98 from 192.168.88.1
pppoe,ppp,debug,packet <addr 78.92.225.101> in 3-Mar 17:55:37.10 from 192.168.88.1
pppoe,ppp,debug pppoe-out1: IPCP opened in 3-Mar 17:55:37.10 from 192.168.88.1
pppoe,ppp,info pppoe-out1: connected in 3-Mar 17:55:37.10 from 192.168.88.1
#1252 re_mod tag dchard #1251

Új Válasz 2012-04-22 15:33:08 #1252
Ú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

re_mod

tag

válasz dchard #1251 üzenetére

Azt szeretném még megkérdezni mert tavaly nyáron azt mondták hogy ha nincs szinkron vesztés ellenben szakad a kapcsolat az is lehet a modem hibája. Jelenleg 200%-os marginnál tartok de így is dobja a vonalat mikor beindul....
Azt vettem még észre hogy szinkron után kiírja hogy a relatív capacity: 74% de mikorra megszakad ez az érték felmegy downloadnál 85%-ra az upnál meg 81%-ra. Vagy ez teljesen lényegtelen ebből a szempontból?
Meg az hogy nem tudom akkor sem kellene szakadnia ha nincs QoS a routerben meg egy úgy általában ezzel a szakadással mit lehet kezdeni mert zavaró hogy akár egy Linux ISO letöltést nem tud végig vinni szakadás nélkül. Ha nincs adatforgalom ilyen szinten kihajtva elmegy akár napokig is.
Ill a bithibáknál lévő szám az mindig ilyen "magas" az up esetén már mikor felszinkronizál egyből:
Status: Showtime
Retrain Reason: 8000
Max: Upstream rate = 1343 Kbps, Downstream rate = 13672 Kbps
Path: 0, Upstream rate = 1085 Kbps, Downstream rate = 11483 Kbps
Link Power State: L0
Mode: ADSL2+
Trellis: UN /DN
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 15.6 18.0
Attn(dB): 13.0 7.1
Pwr(dBm): 18.8 13.3
ADSL2 framing
MSGc: 59 17
B: 118 95
M: 2 2
T: 3 1
R: 10 16
S: 0.6613 5.6026
L: 3000 297
D: 16 2
Counters
SF: 44114 44442
SFErr: 0 0
RS: 4301154 507003
RSCorr: 0 0
RSUnCorr: 0 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 19254659 661394670
Data Cells: 5723647 3803208266
Drop Cells: 9300
Bit Errors: 0 2224619
ES: 0 31408
SES: 0 6
UAS: 34 85035
AS: 711
INP: 0.21 0.43
PER: 16.12 16.10
delay: 2.64 2.80
OR: 32.25 11.42
Bitswap: 39 1
Total time = 13 min 4 sec
SF = 44114
CRC = 0
LOS = 0
LOF = 0
ES = 0
Latest 1 day time = 13 min 4 sec
SF = 44114
CRC = 0
LOS = 0
LOF = 0
ES = 0
Latest 15 minutes time = 13 min 4 sec
SF = 44114
CRC = 0
LOS = 0
LOF = 0
ES = 0
Previous 15 minutes time = 0 sec
SF = 0
CRC = 0
LOS = 0
LOF = 0
ES = 0
Previous 1 day time = 0 sec
SF = 0
CRC = 0
LOS = 0
LOF = 0
ES = 0
Showtime Drop Reason: 8000
Last Retrain Reason: 8000
#1250 re_mod tag dchard #1249

Új Válasz 2012-04-21 18:50:07 #1250
Ú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

re_mod

tag

válasz dchard #1249 üzenetére

15-ös csomag szinkron vesztés még nem volt ember emlékezet óta ellenben a pppoe szakad viszonylag gyakran főleg terhelés alatt (le és feltöltés egyszerre).
Jelenleg 130%-os margin-ál járok ez alatt szakadt még mindig egy idő után.
Az 1251kHz-es eső vivőt már kizártam mint lehetséges hiba forrást de nem segített semmit sajnos.
Jelenleg így néz ki:
ill. DSL informationból:
Status / DSL information
Status: Showtime
Retrain Reason: 8000
Max: Upstream rate = 1332 Kbps, Downstream rate = 15776 Kbps
Path: 0, Upstream rate = 1085 Kbps, Downstream rate = 13489 Kbps
Link Power State: L0
Mode: ADSL2+
Trellis: UN /DN
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 11.9 16.8
Attn(dB): 13.0 7.1
Pwr(dBm): 18.5 13.3
ADSL2 framing
MSGc: 57 17
B: 61 95
M: 4 2
T: 7 1
R: 6 16
S: 0.5869 5.6026
L: 3462 297
D: 16 2
Counters
SF: 52203 52691
SFErr: 2 1
RS: 5755394 601101
RSCorr: 4 0
RSUnCorr: 14 0
HEC: 2 0
OCD: 0 0
LCD: 0 0
Total Cells: 26869810 472103135
Data Cells: 25644833 3757465643
Drop Cells: 26495
Bit Errors: 0 2221650
ES: 1 31381
SES: 0 6
UAS: 33 84544
AS: 845
INP: 0.11 0.43
PER: 16.17 16.10
delay: 2.34 2.80
OR: 31.15 11.42
Bitswap: 68 1
Total time = 15 min 18 sec
SF = 52203
CRC = 2
LOS = 0
LOF = 0
ES = 1
Latest 1 day time = 15 min 18 sec
SF = 52203
CRC = 2
LOS = 0
LOF = 0
ES = 1
Latest 15 minutes time = 18 sec
SF = 1178
CRC = 0
LOS = 0
LOF = 0
ES = 0
Previous 15 minutes time = 15 min 0 sec
SF = 51025
CRC = 2
LOS = 0
LOF = 0
ES = 1
Previous 1 day time = 0 sec
SF = 0
CRC = 0
LOS = 0
LOF = 0
ES = 0
Showtime Drop Reason: 8000
Last Retrain Reason: 8000
#1248 re_mod tag dchard #1238

Új Válasz 2012-04-20 18:27:57 #1248
Ú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

re_mod

tag

válasz dchard #1238 üzenetére

Megfrissítettem a 8810-est és ez jött ki:
Néha most is meg meg szakad de mint írtam valamit variálhattak a rendszeren ezekkel a le és feltöltés priorizálással de még ritkábban ugyan de bont néha a pppoe az adsl link nem.
#1241 re_mod tag dchard #1240

Új Válasz 2012-04-18 08:03:04 #1241
Ú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

re_mod

tag

válasz dchard #1240 üzenetére

Az a helyzet hogy a T1E modemmel is ugyanúgy viselkedik a hálózat azaz egy szál ftp le és feltöltés esetén a letöltés felmegy kb. 1.4MB/s-re a feltöltés meg olyan 50kB/s körül.
Lehet hogy akkor központilag állíthattak valami priorizálást mert ebben már más a chipset.
Tegnap megnéztem egy másik végponton is egy régi barna D-Link-el és ott is ugyanúgy állnak be a sebességek. Nem tudom mikortól de szerintem mostanában változtathattak valamit.?
#1236 re_mod tag

Új Válasz 2012-04-17 17:44:58 #1236
Ú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

re_mod

tag

A D-Link DSL-360R T1E tip. modemnél mitől lehet hogy nem lép be a DMT programnál elvileg minden be van állítva ip cím jelszó és felhasználónév de mégsem fogadja el. Mintha rosszul adnám meg nevet és jelszót. Máskülönben beenged a modem menüjébe ugyanezekkel az adatokkal.
#1234 re_mod tag

Új Válasz 2012-04-16 20:31:22 #1234
Ú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

re_mod

tag

Sziasztok!
Ide keveredett egy TP-LINK TD-8816B tip. modem amiről nem sok jót hallottam. Érdekes módon ezzel a típussal teljesen jól megy a 15megás sebesség, ellenben a 8810B-nél "torrent terhelés" közben főleg ha egyszerre megy full letöltés és feltöltés folyton megszakadt. Két darabbal is próbáltam.
Anno tavaly nyáron kínlódtam ezzel de nem sikerült zöld ágra vergődni a T-Home-al ez ügyben.
A 8816-al viszont teljesen hibátlan terhelés alatt is viszont olyat vettem észre mintha valami csomag priorizálás lenne mert pont fordítva működik mint eddig, ha a letöltés és a feltöltés is menne akkor nem a feltöltés gyorsul a letöltés kárára max.-ig hanem fordítva.
Tehát ha mondjuk jön valami 1.3MB/s-el akkor a feltöltést "lelassítja" addig hogy a letöltés fullosan ki tudja magát hajtani ha leállítom a letöltést vissza megy a feltöltés is. Néztem a menüjében van benne valami adsl qos funkció de hiába próbálkozok UBR vagy CBR ill. van még kettő de bármit állítok be csak lassabb lesz az egész ill. azt sem tudom van e erre hatása.
Most ez a modem marhasága vagy valami így lett beállítva központilag? Megszűnne-e a hiba egy T1-es D-Link-el vagy nem ettől van? Mert a 8810-ben is ugyanaz a chipset és megsem jó ezzel meg igen. Ill. abból a szempontból hogy nem szakad fullon sem.
Az SM50-b nem ismeri fel pedig fel kellene neki ha ez TrendChip-es vagy nem?