Új hozzászólás Aktív témák
-
csiga997
őstag
Ne csúsztassunk! Nem azt mondtam, hogy a DIX ugyanaz, mint a 802.3, hanem, hogy minimális a különbség. És ez igaz is (a 802.3=DIX2.0+LLC header).
Ha figyelmesebben olvasol, akkor láthatnád, hogy az ATM-ről és az MPLS-ről beszéltem. Mindkettő L2 protokoll.
Az IETF protokolloknak nem kell 'ingyenesnek' lenniük, erről szó sincs. Pusztán annyi a követelmény, hogy ha egy contributor a saját szellemi termékét a szabvány részeként publikálja, akkor az témában esetlegesen létező szabadalmait licenszelnie kell fair, reasonable és non-discriminatory módon. -
bambano
titán
Ne keverjük a dix ethernetet a 802.3-mal. Az atm-ip összehasonlítással meg az a baj, hogy nem ugyanazon dolgokat hasonlítod össze. Az atm osi modell szerinti 1-2 rétegbeli protokoll, az ip meg internet stack szerinti harmadik rétegbeli. Az mpls-sel korábban az ingyenessége volt a gond, nem tudom, ezt megoldották-e azóta. Régebben nem lehetett rfc-ben pénzes protokoll, az mpls-nek van már rfc-je, remélhetőleg a cisco nyílttá tette a protokollt.
-
csiga997
őstag
Rengeteg eset van, amikor egy gyarto meglevo megoldasat egy-az-egyben vagy igen
minimalis valtoztatasokkal szabvannya emelik. Pl Spanning Tree (Digital Equipment)
- IEEE802.1d, Ethernet (DEC-Intel-Xerox DIX) - IEEE802.3, Cisco
Tag switching - MPLS, es meg lehetne sorolni.
..
Egyebkent - ha elolvasod figyelmesen amit irtam - nem a szabvanyugyi szervezettel van a problema onmagaban, hanem ha az az adott szervezet nem elegge rugalmas es tulburokratizalt. Az ATM forum ilyen, az IETF meg nem. Ennyi. -
#63
Taltosparipa
tag
Taltosparipa
tag
Hitvita nelkul, ilyen cumonak ott van ertelme ahol az user nem akar szoftveres buheralast es nem kell neki router. De ahoz kepest az ar lesz majd donto es persze mi lesz alapban bekonfigolva.
-
#61
csiga997
őstag
shabbarulez
#57
csiga997
őstag
válasz
shabbarulez
#57
üzenetére
Mondom én: az ATM halott.
ATM gerinchálózatot már csak azok építenek, akik valamikor 10 éve bementek a csőbe és most próbálnak tovább evickélni. Access hálózathoz ATM-et használni is tragikus tévedés volt, de lassan majd onnan is kikopik. Az a baj, hogy az ATM egy szabvány-sóhivatalok által erősen túlszabályozott, túlbonyolított és emiatt aztán a végén senkinek sem megfelelő technológia, míg hozzá képest az IP jóval organikusabban fejlődik. Az ellentmondások már annyira az alapokban vannak elrejtve (pl. a 48byteos payload méret*, ami se hang- se adatátvitelre nem optimális (az egyikhez kisebb kéne a másikhoz meg nagyobb), aztán a rengeteg adaptation layer, amiből aztán a végén kettő van ami értelmes, és még lehetne sorolni), de legfőképpen a háttérben meghúzódó vonalkapcsolt gondolkodásmód az ami a legnagyobb hátulütője a technikának és leginkább emiatt válik mindinkább túlhaladottá.
Persze, az IP technológia is hordoz magán elég ballasztot és egyre komplexebb lesz az is (az MPLS TE és mondjuk a RIPv1 bonyolultsága szinte össze sem hasonlítható), de még mindig jóval átláthatóbb, és főleg sokkal szélesebb körben gyakorolt iparág mint az ATM. Amíg pedig 20 IP-s mérnökre jut 1 ATM expert, addig nem is lehet belőle semmi, mert amihez senki nem ért azt nem is lehet jól megcsinálni.
* A 48 byte úgy jött ki, hogy a hangátvitelesek 32 byte-ot akartak az adatosok meg 64-et, és a vita odáig fajult, hogy még össze is verekedtek az öltönyös urak rajta.
Végül aztán huszárosan vették a kettő átlagát, amolyan dögöljön meg a szomszéd tehene is módra... 
-
#57
shabbarulez
őstag
bambano
#55
shabbarulez
őstag
Megnézted már annak a PDF-nek a dátumát? 2000.07.17, az bizony már nem tegnap volt, azóta elég sokat változott a távkölés, trendek jöttek, trendek mentek. Maga az egész szövegezés igen erősen fatáv szájízű, már ahogy kezdődik:''a 2000-es években is szükség van még rézvezetős előfizetői hálózatra''. Jah persze, de csak azért mert az inkubens telconak az az üzleti érdeke hogy ez így is maradjon hisz csak így tudja a végsőkül kisajtolni azt ami a rézhálózatában és a PSTN távközlési hálózatában van. Maga az egész ADSL arra lett kitalálva hogy a telcok rézbázisú infrastruktúrájának életciklusát még tovább ki lehessen tolni alapvető fejlesztések nélkül.
De amint valahol kiépülne egy optikai párhuzamos infrastruktúra onnantól a rézbáziú értéke azonnal a nullára zuhanna és totálisan elértéktelenődne ami persze a telecom cégeknek nem érdekük és ezért mindent meg is tesznek hogy ez a rendszer továbbra is fenn maradjon.
Visszatérve az ATM-re. 2000-ben még valóban az ATM alapú DSLAM-ok domináltak mivel csak azok voltak, de úgy 3-4 éve feltüntek az IP alapú DSLAM-ok és azóta egyre nagyobb mértékben veszik át a pályát, a mai fejlesztések szinte csak erre alapoznak és a régi ATM-es konstrukciók idővel teljesen kikopnak. A PDF megírása óta volt egy alapvető szemlélet váltás a távközlésben, a régi E3, STM-1-es felhordóhálókat folyamatosan lecserélik a nagyobb kapacitást kínáló és jóval olcsóbb IP alapú Gigabit Ethernetre.
A Tíkom is anno már a 2000-es évek elején megkezdte saját gerinchálózatának átalakítását ezen trendeknek megfelelően, aztán ezt folytatták a felhordó hálózatoknál egészen a DSLAM-ok uplinkjének lecserélésével. Az új berendezések az elmúlt 1-2 évben már ilyenek voltak de most ősztől májusig volt egy átfogó fejlesztési project az IP alapú technológiákra való mégnagyobb átállás és ADSL2+, majd az eljövendő IPTV alapjainak megteremtése céljából.
Az ATM kiszorulását az új technológiát eljövetele hozta el, a Triple Play eszközök és szolgáltatás kínálat egyre nagyobb sávszél követelményeket támasztott úgy hogy az áraknak ezzel ellentétesen egyre csökkenő tendenciát írjanak le és ennek a kívánalomnak az ATM-es rendszerek nem tudtak megfelelni. Az Ethernet viszont szépen kinőtte magát az elmúlt években akár gerinchálózati akár felhordó hálózati fronton, és mostanában még jobban népszerűbbé válik.
Az utolsó szakaszon a DSLAM és a modem között van még ATM, de lehet már ott sem sokáig. A full IP tendencia egyre jobban teret nyer. Már jó ideje az újabb szabványok támogatják az IP alapú packet mode-ot amivel szintén ethernet alapú lehet a végső szakasz is. Akár a PPPoE-t is el lehetne felejteni is egy sima LAN hálóhoz hasonlóan DHCP-vel csatlakozni mint egy LAN vagy kábelnetes hálózat esetén.
Ezért írták korábban hogy az ATM egyre kevésbé bír már befolyással, gerinchálózatoknál az MPLS veszi át a helyét és az Ethernet ott is egyre nagyobb teret nyer, felhordó hálózatoknál már most is igen komoly szerepe van és a felhasználóhoz való csatlakozások terén is egyre nagyobb teret nyer.
Pl. az ADSL-es rézbázisú csatlakozásokat idővel leváltó optikai megoldások közel Passzív optikai hálózatoknál(PON) a legnépszerűbb variáns szintén az ethernethez kötődő E-PON, az aktív optikai megoldásoknál is szintén az Ethernet a legdominánsabb.
Szóval arra is kell figyelni mikor íródott az a cikk mert a távközlésben 6 év igen nagy idő, az alatt sokat tud változni a világ. -
bambano
titán
Mert a cikkből kiderül, hogy az adsl dslam és az adsl nt között az adsl atm-et használ. Tehát sem az az állítás nem igaz, hogy az adsl halott, sem az, hogy a gerincen kívül nem használják. Nem tartom kizártnak, hogyha utánanéznék, kiderülne, hogy a docsis szabványú kábelmodemek is atm alapú hálózati cuccot csinálnak.
-
Cs_Laci
senior tag
Az hagyján, de mi van azokkal, akik pl E-Mule t használnak?? Ott ez az arány nagyon nincs így
Szegény csacsizók mindig megszívják.
Amúgy meg az ATM szép meg jó, de az is egy megerőszkolása a technológiának, amikor te ATM-be belecsomagolsz meg kicsomagolsz pl a TCP/IP szintig. Az sem egy triviális művelet drága kapcsolókkal..... Szóval még mindig elemi szinten vannak a gondok SzvSz... -
Cs_Laci
senior tag
Fortyogás ON
Annyira imádom az Informatikát.. 25 000 problémát felvet, ami Informatika nélkül nem lenne.. Pl ha végre kitalálnának valami QoS-t nyújtani képes Transport Layer-t, akkor nyilván ilyen eszközökre nem lenne szükség.. De ezt nagyon régóta képtelenek megtenni, úgyhogy elterjedt ez a Remek Ethernet.. Ami aztán sokmindenre innentől kezdve csak erőteljes megerőszakolás után alkalmans.. Ez az eszköz egy ékes példája.. ..
Fortyogás OFF
Amúgy szoftveresen 1 gép esetén Win alatt lehet valahogy csomagoptimalizálást csinálni? -
csiga997
őstag
...vagy pedig agyatlanul megfékez minden olyan tcp sessiont, ami nem high-priority, voip, streaming, stb.
PPP kapcsolat nélkülö protokoll, nincs semmiféle sorrend-vizsgálat. Tehát akár meg is előzhetik egymást a frame-ek, bár ez egy soros vonalon tipikusan nem jellemző. Ettől függetlenül nincs erre megkötés. -
#33
bambano
titán
janpotocki
#28
bambano
titán
válasz
janpotocki
#28
üzenetére
Az a sejtésem, hogy ezzel tönkretennéd a voip azon elvárását, hogy a csomagok késleltetése ne legyen nagy szórású és előre megjósolható legyen.
Ha eldobsz egy csomagot, az csak a tcp window size kitöltése után fogja megállítani a feladó gépet, aki várakozni fog a tcp ack-ra, de az nem jön meg, de addigra a teljes window size mennyiségű adatot beletolta már a hálózatba. Majd időzítés lejárása után újraküldi azt az egy csomagot, mire te ezt már elfogadod. A fogadó gép tcp szoftvere pedig az egész window size-t le fogja nyugtázni, mert addigra minden adat megjött, a feladó pedig megörül, hogy minden odaért, újabb adag window size méretű adatot tol a drótba. Ami szépen ki fogja sámfázni az adsl-t. Vagyis úgy fog kinézni a nagy letöltésed, hogy minden másodpercben kb. 1/3 másodpercre kisámfázod ezerrel a drótot, ekkor a voipod recsegni fog, majd egy darabig üres lesz. (300kbyte/sec letöltési sebességgel és 128k window mérettel saccolva). -
VladimirR
nagyúr
ezt a befele semmi beleszolasom nincs dolgot nem igazan ertem
nem ugy van (tanitottak valami ilyesmit), hogy ha nem kapja meg a kuldo az ack csomagot, akkor ujrakuldi ugyan, de ''lassabban'' (valami frame meret csokkentes remlik, de nem akarok hulyeseget mondani - be kellett volna jarni eloadasra)?
mert ha ez valoban igy van (es nem csak hulyesegeket beszelek), akkor megiscsak tudom szabalyozni a bejovo forgalmamat (megha kozvetve is, ugy, hogy a kuldo kimenojet szabalyzom...) -
Eperfa
tag
őszintén nem értem mi a bajotok a ketyerével.
van itthon 2 gép. nálam általában bentvan vmilyen filemegosztó progi (éppen emule, de sokat nem számít), bátyám szeret játszani (az egyébként híresen szar multiplayer-kódú mohaa-val).
ahhoz, hogy ő játszani tudjon, nekem irreálisan kicsire kell korlátoznom (a saját gépemen, software-esen) a feltöltésemet (egy pár k feltöltési sebesség felett már lagol az ő játéka), ugyanakkor nyilvánvaló, hogy ennél sokkal többet is meg lehetne reálisan oldani
pont erre való ez a kis szar. a mostani linksys routeremben is van qos, és nem kell semmi egetverő dolgora gondolni, semmi csomagelemzés,s tb, egyszerűen a küldő port alapján lehet beállítani a priorityket. igen valószínűnek tartom, h ez is pont uígy működik. az egy más kérdés, h a mostani routerem alap firmware-jével egyszerre csak egy portra leeht megadni a priorityt, összesen pedig 8ra, tehát egy ezres nagyságrendű porttartományt használó játéknál keveset segít a dolog, demajd átégetem a firmware-t, rem akkor már lehet porttartományokat definiálni
szóval sztem nem kell annyira fikázni a dolgot, soho/home eszköz, és arra nagyjából megfelelő -
bambano
titán
Két utat látok: precízen visszafejti, hogy a dugulást melyik tcp session okozta és azt az egyet fékezi meg ack delay-jel vagy agyatlanul minden tcp sessiont megfékez ezzel. Utóbbi esetben kockáztatja azt, hogy olyan sessiont is lefékez, amit egyébként nem kellene.
A ppp sorrendtartására vonatkozó kérdésemben azt akartam kérdezni, hogy a ppp a soros dróton nem változtatja meg a csomag sorrendjét. A kérdés az, hogy a protokollhoz tartozó állapottérben ezt ki is használják-e vagy sem. Ha azt alapértelmezem, hogy a csomagok sorrendje nem változhat, akkor csinálhatok olyan protokollt, amiben ellenőrzöm pl. sorszámmal a csomagokat és ha egy kimarad, akkor azt hibaként detektálom és megvárom az újraadást. Vagyis elvileg előfordulhat, hogy a ppp protokoll úgy van definiálva, hogy ha nem sorrendben érkeznek a csomagok, akkor az hibára utal és megpróbálja visszaállítani a sorrendet. Ebben az esetben ha a dobozka felcseréli a tcp ackok sorrendjét az ack-delay miatt, akkor felborulhat a gép-adsl modem kapcsolat. Ha nem cseréli fel, akkor meg maga a dobozka okozhat voipban késleltetést.
Lehet, hogy nem sikerült jól leírnom, amit mondani akkarok, sorry. Ehhez kellene pontosan ismerni a ppp-t. -
#28
janpotocki
senior tag
bambano
#25
janpotocki
senior tag
ok, ez mind világos, nyilván nem arra gondoltam, hogy a már dróton lévő adatok beömlését szabályoznám. de a csomageldobálás nagyon is hatékony megoldás lehet, mert (záros idő után) eleve kevesebb adat kerül a drótra. felemás, buhera megoldás, főleg a diffserv és társaihoz képest, de mentőöv lehet. abba egyáltalán nem szeretnék belemenni, hogy ez dollárban kifejezve mennyit érhet
szerk.: öcsém igazából nincs, így nem sokat -
VladimirR
nagyúr
ne, fokent, hogy ezt a szoftveres megoldast megkaptam 3k-ert
de van, akinek ez nem megfelelo, mert mint janpotocki is irta, elofordulhat, hogy tobb gep van a ''haztartasban'' (irodaban, kinek mi), es ezesetben nem mukodik a szoftveres megoldas
mondjuk en ezesetben is inkabb osszedobnek egy p1-est routernek, ra meg valami kimondottan ilyen celra keszult os-t (pl a coyote linux nekem tetszett anno, mikor hasznaltam, es qos is van benne - legalabbis asszem a coyote volt az) -
#25
bambano
titán
janpotocki
#20
bambano
titán
válasz
janpotocki
#20
üzenetére
Arról szól ez a thread, hogy a befelé jövő forgalmat nem tudod szabályozni, nem csak ezzel az eszközzel hanem mással sem. Ez a dobozka a kifelé menő forgalmadat szabályozza. Itt a befelé jövő forgalom alatt nem azt kell érteni, hogy letöltés vagy webezés, hanem ip/ethernet csomagok szintjén a nyers forgalmat.
Ha elindítasz egy letöltést, az az egy darab letöltés, ami gyakorlatilag arról szól, hogy kintről, világvégéről bejön hozzád egy állomány, egyszerre generál bejövő és kimenő forgalmat is. Jön be az anyag, kisebb adagokra bontva, a te géped időnként szól a szervernek, hogy az eddigieket rendben megkapta, küldje a következőt. Ezen két forgalom aránya 1:10 vagy még rosszabb, vagyis egységnyi kimenő forgalomra legalább 10 egység bejövő forgalom jut.
Ha a szolgáltatód már beletolta abba az atm pvc-be a csomagot, ami neked szól, azzal te már semmit nem tudsz csinálni, mivel a szűk keresztmetszet a szolgáltatódtól az adsl modemedig terjedő drót. Ha már átjött az anyag a szűk keresztmetszeten, azt már kevéssé értelmes tovább babrálni.
Ha az öcséd kekeckedik veled és te hozzáférsz a routerhez, hogy rádugj egy ilyen dobozkát, akkor sokkal olcsóbb megoldás kihúzni a routerbe integrált switchből az öcséd ethernet drótját és hidd el, mindjárt megjavul a tárgyalási kézsége. -
csiga997
őstag
Egy ideális világban ugye elég lenne csak a DSCP mezőt kiolvasni az IP fejlécből, de ugye ez nem egy ideális világ...
Kicsit butább módon elég lehet, ha a tcp/udp portszámokból ''felismeri'' a high-priority forgalmat, minden más pedig best effort és lehet sanyargatni. Ez viszont erőforrás-igényes.
A PPP L2 protokoll és annyiban sorrendtartó, hogy soros vonalon nem szokás egymást előzgetni a csomagoknak. Viszont az IP szinten már lehet OOP ami nem lenne szabad, hogy gondot okozzon, mivel az IP connectionless protokoll. Persze, a felsőbb layereken ez már okozhat gondot, és tipikusan a voip ilyen, ami nem szereti, ha beelőzgetik egymást a csomagok. De lehet pl. selective discard-ot is csinálni a best-effort forgalomra, igaz, ezzel jól megszivatja csak magát az ember, viszont a szkájpin rezzenéstelen lesz a kép amíg a letöltés a háttérben 2x annyi ideig tart majd. Dehát valamit valamiért, ugye.
[Szerkesztve] -
#22
VladimirR
nagyúr
janpotocki
#9
VladimirR
nagyúr
válasz
janpotocki
#9
üzenetére
egen, ebbe akkor lehetne belemenni, ha tudnank, mi is van az eszkozben, es mire kepes
-
#20
janpotocki
senior tag
bambano
#14
janpotocki
senior tag
most már kezdem magam kínosan érezni, mert nem akarom védelmembe venni ezt az eszközt, de nem sikerült felfognom azt sem, miért ne lenne abszolút semmi értelme. igaz, a bejövő forgalomra csak a modem után van hatásköröm. legegyszerűbb, ha szoftveresen, a pc-n megfogom, ha épp nem érdekem, hogy mind a 2 megabitet kitöltse. de teszem azt, hozzá nem értő felhasználó vagyok, vagy az öcsém bosszújának esem áldozatul, aki pofonmentesen lezárt szobájában bittorentezik etc. ilyenkor jó esetben átszabom a sávszélességét a routerben, de ha erre nincs mód, beteszek egy efféle eszközt. ha jól működik (nem tudom, ez konkrétan hogyan működik), és tudja, hogy nekem a voip-hoz mindkét irányban szükségem van x sávszélre, akkor időnként csomageldobálással megfoghatná a bejövő forgalmat is, így egy idő után (a windowing miatt) a szerver eleve lassabban öntené az adatokat. és ez az egész a 2 megabitről szól, utána a 100 megabites lanon már senkit nem érdekel, hogyan mennek az adatok, van helyük. nem?
-
bambano
titán
Ahhoz, hogy a doboz delayed ack-ot tudjon, értelmeznie kellene a teljes adatfolyamot. Ehhez ki kellene csomagolnia a ppp over ethernetet, azon belül az összes gép összes tcp kapcsolatát nyomon kellene követnie és minden tcp sessionra külön meg kellene ezt csinálni, majd az egyészet újra összerakni. Nem tudom fejből, hogy a ppp protokoll szükségképpen sorrendtartó protokoll-e, ennek utána kellene nézni, mert ha igen, akkor ez nem működik.
Ha leküzdöm a szkepticizmusomat, hogy egy kis dobozkában fillérekért mindezt megéri megcsinálni, akkor tudom mondani, hogy igazad van és érdemes ilyenbe beruházni. Egyéb esetben csak azt tudom mondani, hogy igazad van, spanyolviasz feltalálás esetét láttuk -
#17
csiga997
őstag
janpotocki
#10
csiga997
őstag
válasz
janpotocki
#10
üzenetére
A befelé jövő forgalomra semmi hatásod nincs, csak az általad generált forgalmat tudod korlátozni és szabályozni. A befelé jövő forgalmat, ha már egyszer az ISP oldalán letorlódott, akkor a te eszközödben csak legfeljebb még jobban meg tudod nyomorgatni, pl azzal, hogy eldobálod a nagy nehezen beérkezett csomagokat vagy pedig nem küldesz acknoweldge-et a beérkezett csomagokra és a forrás majd valamikor később újraküldi. De ezzel nem nyersz plusz sávszélességet a ''fontos'' voip és egyéb forgalmad számára, mert azt a szűk keresztmetszet elején, vagyis az adsl/cable linked másik végén azaz az ISP oldalán az ISP-nek kéne külön forgalmi osztályok és prioritások szerint kezelnie. A mai ISP viszont ilyet nem csinál.
-
#14
bambano
titán
janpotocki
#10
bambano
titán
válasz
janpotocki
#10
üzenetére
Mert a te bejövő forgalmadra csak az adsl modem után van hatásköröd. Annak meg sok értelme nincs, hogy bejön egy-két megabiten egy forgalom, amely drót konfigurálására nincs lehetőséget, majd utána kezdj el sávszélességet macerálni, amikor a két megabit átkerül a 100 megás helyi hálózatra.
-
csiga997
őstag
Konkrétan senkinek nem lesz jobb, amíg nincs end-to-end diffserv támogatás a távoli szerver és a kliens között, vagy RSVP, ami méginkább nincs.
A csomag priorizálását az adatfolyam forrása képes megtenni, tehát az uplinket lehet befolyásolni. A letöltés helyén maximum a nagyforgalmú adatfolyam blokkolásával lehet sávszélességet felszabadítani (pl. delayed TCP acknowledge-ekkel lassítani a letöltést) de lényegében ez is az uplink forgalomba való beavatkozást jelent. Ha a szerver és a kliens végpont közötti downstream szolgáltatók (az összes!) nem támogatják az eltérő forgalmi osztályok szerinti csomagütemezést akkor a végén minden ugyanabba a traffic-classba fog tartozni, amit a szolgáltató szépen beönt ugyanabba a csőbe azt lesz ami lesz. -
#12
bambano
titán
janpotocki
#9
bambano
titán
válasz
janpotocki
#9
üzenetére
Úgy érted, hogy a 100 megás saját lan késleltetni fogja azt a forgalmat, ami bejött a néhány megabites adsl-en vagy csellón?
Tökéletesen igazad van abban, hogy priorizálni a forrásnál célszerű, ezt én még megtoldanám azzal a kitétellel, hogy akkor, ha szűkös, túlterhelt a sávszélesség. A letöltésnél a sávszélesség lehet szűkös, de annak a forrása a világvégén van, sőt, a letöltés és a voip forrása nem is feltétlenül egy helyen. Az első közös pont, ahol a két forgalom biztosan találkozik és reális esélye lenne a qos-nak vagy a korlátozásnak, az az ISP és az adsl carrier szolgáltató routerei közötti link (az ''adsl carrier szolgáltatás átadás-átvételi pontja''). Erre tudtommal nincs ráhatásod.
A kifelé menő forgalom forrását pedig el tudod kapni, mert az lakáson belül van, erre viszont a fenti példa alapján nem érvényes a szűkösség kitétel.
A szolgáltató szerintem nem foglalkozik azzal, hogy milyen kimenő forgalmad van, biztosan nem fogja csereberélni a csomagok sorrendjét, hanem ami felcsorgott tőled 256k-val, azt ő a sok tíz vagy száz vagy gigás gerincén villámgyorsan kitolja a világba.
Még mindig nem látom értelmét annak, hogy a kifelé menő irányon van ilyen egy csomag-nagy szünet-egy csomag-nagy szünet jellegű forgalom, azon mit kell macerálni drága dobozzal. -
VladimirR
nagyúr
kishazankban a nagy sebessegu letoltes mell altalaban feltoltes is jar, es nem csak ack csomagok kepeben, mivel eleg nepszeruek a filemegoszto programok
szoval tobbnyire van ott kimeno forgalom, es ekkor igenis hasznos a qos
en cfosspeed-et hasznalok, elegge meg vagyok elegedve, nelkule nem igazan volt hasznalhato a net, ha beingitottam a dc-t -
#10
janpotocki
senior tag
bambano
#7
janpotocki
senior tag
miért ne tudnék hatással lenni a befelé jövő forgalomra? azt mondom például, hogy csak x sávszélességet kap, de csak akkor, ha nem gátolja a bármilyen irányú voip-forgalmat. ez esetben csökkentem a sávszélt, vagy ha van alkalmas eszközöm ideiglenesen várakoztatom a csomagjait, hiszen letöltésnél mindegy, mekkora a késleltetés/jitter
-
#9
janpotocki
senior tag
VladimirR
#6
janpotocki
senior tag
érteni vélem, de ha feltesszük, hogy a túloldalon minden rendben és az internet sem fogja meg a voip-csomagokat, akkor marad hibalehetőségként a saját lan, és ezen segít ez az eszköz. azt, hogy priorizálni a forrásnál célszerű, általános elvként írtam.
egyébként könnyen elbeszélhetünk egymás mellett, hiszen nem tudni pontosan, mi lakik a belsejében, egy egyszerű sávszélesség-menedzsment, vagy vmi komolyabb qos mechanizmus (azaz, hogy jelöli-e vmi módon a kimenő csomagokat, vagy csak magának állít fel egy fontossági sorrendet, illetve ha az előbbi, mi az esély rá, hogy a szolgáltató nem bírálja ezt felül csípőből) -
bambano
titán
A beszélgető partnernek se lesz jobb. A nagy állományok letöltése legrosszabb esetben is 9-10x annyi bejövő forgalmat generál, mint kimenőt. Tehát egy 768/256-os adsl-en csinál 768 bejövő és kb. 80 kbit/sec kimenő forgalmat. Ráadásul a kimenő csomagok rendszerint kicsik, csak tcp ack és hasonlók vannak benne. A 256-os sávszélesséből még marad 150-160 kilobit/sec üresen, a késleltetés se változik nagyon 80-100 byetos csomagok miatt. Egy majdnem üres dróton mit variál ez a doboz?
-
#7
bambano
titán
janpotocki
#5
bambano
titán
válasz
janpotocki
#5
üzenetére
A letöltés a világból befelé, a gép felé jön és relatíve kevés ráhatással tudsz lenni. A letöltésnek az a része, amelyik kifelé megy, elenyésző méretű csomagokból áll. Ha elkezdel letölteni egy nagy állományt, akkor a kifelé menő irányban nincs torlódás, azon nincs mit szabályozni.
De ez természetesen csak a webes vagy ftp-s letöltésre igaz. Ha olyan hálózatot használsz, ahol a policy az, hogy neked is szolgáltatnod kell (köteles vagy te is megosztani, vagy a te géped is feeder lesz, mint pl. bittorent), akkor elvben lehet komoly kimenő forgalmat generálni. De minek veszel dobozt azon forgalom megregulázására, amit a bittorent kliensben egyébként is lehet korlátozni? Az mennyire életszerű feltételezés, hogy valaki profin voipol, letölt ezerrel és nincs ráhatása a gépekre?
Tehát ez a dobozka továbbra is a spanyolviasz kategória. -
#6
VladimirR
nagyúr
janpotocki
#5
VladimirR
nagyúr
válasz
janpotocki
#5
üzenetére
szerintem arra celzott bambano, hogy ha vesz a user egy ilyet, attol neki nem lesz jobb
a beszelgetopartnerenek, aki az o bamba kepet bamulja a neten keresztul, annak igen, de a mi user-unknek nem (hacsak nincs a masik felnel is egy ilyen ketyere) -
#5
janpotocki
senior tag
bambano
#4
janpotocki
senior tag
nincs ebben ellentmondás, hiszen a voip (váltakozó irányú adatforgalom) egyik forrása a felhasználónál van, és ott előnyt biztosít neki ez a szerkezet a letöltéssel szemben. tény, hogy az interneten még bármi megeshet a voip csomagokkal, de a felhasználó oldalán legalább rendben vannak. a voip-es pc-n hiába priorizálod a forgalmat, ha a letöltés egy másik gépen megy, és a router nem ismer qos-t.
-
bambano
titán
Gondolom a cikk egy az egyben átvett valami marketing anyagot, mert amit ide írt, az önmagában is ellentmondásos. Ha a nagyméretű letöltések melletti voipozáson akar segíteni azzal, hogy a forráshoz közel vizsgálja a forgalmat, akkor az nem az előfizetői adsl modemnél van, hanem ott, ahol a letöltés szervere van, esetleg az adsl carrier szolgáltató forgalomátadási routerében. A kimenő forgalom szabályozásának elvben lenne értelme, de egyrészt az nem a letöltéskor számít, másrészt azt ténylegesen a forrásnál, vagyis a pc-n futó oprendszerben kell/érdemes csinálni. Ennek az eszköznek a hasznossága szerintem egyenlő a dvd visszacsévélő gép hasznosságával.
A linksysnek meg további gondolkodásmentes jónapot kívánok. -
VladimirR
nagyúr
ne beszelj mar fas....ooo....butasagokat, miert tiltana be?
tudom, most jon az, hogy ''de bezzeg a cfos....'' - egen, par orat le volt tiltva, mert csak annyi latszott, hogy egy ip-re nagyon nagy forgalom megy, dos-nak veltek, levagtak
miutan kiderult, levettek a tiltast, azota egy parc kihagyas nem volt
azt aruld mar el, miert kell mindenbe belekeverni az esz nelkuli fikazast? nem volt gyerekszobad?
a kerdesed nem teljesen tiszta, de nem te kapsz prioritast, hanem bizonyos csomagtipusok - letolteni nem fogsz gyorsabban, de a game, es a a/v atvitel (elvileg) nem fog akadozni
engem inkabb az erdekelne, hogy mi alapjan ad ez kisebb/nagyobb prioritast a csmagoknak? port alapjan? -
orbano
félisten
Aztán majd a tré-online ezt is betiltja, és a linksys weboldalát majd nem lehet elérni sem... kíváncsi vagyok, letöltés közben mennyi lenne egy ilyenne la pingem.
Egy másik kérdés pedig: ha ezt bekötöm mondjuk a gépem és a wifi access point közé, akkor elérhetem vele, hogy prioritást kapjak aznon a hálózaton, amire csatlakozok és ahonnan a netet is kapom? -
sTERNI
senior tag
Tesztet kérünk szépen (majd)
Sok helyen olvastam már ilyen kütyüről, nem egy embernek jutott eszébe ilyesmi; de, ha beválik és a licenszekkel sem lesz nagy probléma... akkor szerintem hamar el fog terjedni, idővel pedig valami beépített (routerbe, hálózati csatolókba) verziót is el tudnék képzelni.
Végül aztán huszárosan vették a kettő átlagát, amolyan dögöljön meg a szomszéd tehene is módra... 
Új hozzászólás Aktív témák
- Fejhallgató erősítő és DAC topik
- Milyen autót vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- bitblueduck: RTX 50-es széria PhysX támogatás nélkül. Tényleg akkora probléma?
- Konzol Screenshot
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- További aktív témák...
- Apple Watch Series 4 Nike 44mm Teljes doboz, sok tartozék, 100% akku
- LG 77C4 - 77" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - 1000 Nits
- Dell G15 5530 gyári kijelzőt keresek (DP/N: 0VPD4)
- IDE HDD-k vegyesen nagy mennyiségben 32db egyben
- Eladó gamer / workstation PC + monitor garanciás, dobozos alkatrészekkel
- BESZÁMÍTÁS! 1000W Sesonic FOCUS GX-1000 Gold tápegység garanciával hibátlan működéssel
- HP ZBook Studio G7 i7-10850H 32GB 1000GB Nvidia Quadro T1000 15.6" FHD 1 év garancia
- BESZÁMÍTÁS! ASUS Prime H370 i5 8600K 32GB DDR4 512GB SSD RTX 2060 Super 8GB Zalman N5 BitFenix 550W
- Azonnali készpénzes AMD Ryzen 1xxx 2xxx 3xxx 5xxx processzor felvásárlás személyesen / csomagküldés
- iKing.Hu - Honor Magic 5 Pro 5G - Használt, újszerű állapotban, ajándék tokkal!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest