Keresés

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

  • ecaddict

    senior tag

    válasz And #7667 üzenetére

    Nem WRT54G routerem van (hanem WL500gP, HW-modos, 128M RAM-al) és sávszél managment-et sem használok, de a dolog általános volta miatt egy két gondolat.

    A forgalom szabályozás nem csupán a tc parancsok bonyolultsága (ill. azok gyenge dokumentációja) miatt zürös dolog. Tényleg előfordulhat, hogy csak feleslegesen eszi a procit minden hatás nélkül (ill. extrém esetben negatív hatással) ill. a másik végletként csodákat tesz (de ettől persze még több sávszélességed nem lesz).

    Tipikus példák amikor érdemes lehet használni:
    -Relatíve nem túl nagy sávszél rossz uplink/downlink aránnyal (tipikusan DSL variánsok, feltöltés a 1/8 vagy még kevesebb a letöltési sebességnek)
    -Több felhasználó a router mögött és nem szeretnéd, hogy valaki tömeges adatforgalommal tönkretegye az interaktivitást igénylő alkalmazásokat (játékok, chat, böngészés, remote terminal stb) és a szolgáltató nem alkalmaz már eleve valamilyen forgalomszabályozást (vagy az nem érvényesül mert elegendő sávszélessége van a szolgáltatódnak)

    A példákat hosszan lehetne folytatni de nemcsak erről szeretnék most írni.

    Ami egy kicsit megnehezítheti a forgalomszabályozást az az, hogy a forgalom mennyisége időben is és térben is változó. Konkrétan este amikor mindenki netezik (bix.hu) a szolgáltatód is jó eséllyel belefut sávszélesség korlátba mig hajnalban aligha. Hogy ilyenkor mi történek az egyrészt csak sejteni lehet, egyébként meg mivel nincs ráhatásod felesleges találgatni.
    Ilyenkor egy forgalmas webszerver elérése problémás lehet még akkor is, ha a szolgáltató a web forgalmat nagyobb priorítással kezeli. p2p protokol meg még vígan mehet, ha az nem megy át sávszélesség korlátos helyen (pl. közel van a peer).
    Gondolom ilyesmit aki figyelt már észrevett.

    Itt az első gond. Erre az időben és térben (IP cím függően) változó (elérhető) sávszélességre kellene a router forgalom szabályozást csináljon. Azok az algoritmusok amik arra alapszanak, hogy ismert a sávszélességed itt vagy kiesnek, vagy nem mindig lesznek optimálisak.

    Hogy miért is lehet fontos tudni a feltöltési sávszélességed (nem mondtam még igazából csak erre lehet jó forgalom szabályozást csinálni, ami lefelé történik az inkább policing azaz csomagok eldobása abban a reményben, hogy a túloldal visszafogja magát)?
    Ha olyan ütemben küldi a router az IP csomagokat ami át is megy a hálón akkor amikor legközelebb eljut oda, hogy ismét küldhet csomagot ki tudja választani a leggyorsabban küldendőt.
    Ellenben, ha gyorsabban kezd a router küldeni, akkor az valahol fel fog torlódni (várakozási sorba kerül). Ekkor legközelebb hiába is szedi elő a router a leggyorsabban küldendőt az csak akkor fog sorra kerülni amikor az előtte lévő potenciálisan lassabban küldendő csomagok feldolgozásra kerültek (adott esetben ezen segíthet ha a szolgáltató valamilyen forgalom szabályozást csinál).

    Ez alapján azt hiszem már érthető mért pont a DSL-eknél ahol aránytalanul kicsi a feltöltési sávszélesság a leghatásosabb a forgalom szabályozás. Mivel a letöltött csomagokhoz a legtöbb protokolnál tartozik valamilyen visszaigazolás (ami a feltöltési sávszélességed használja), és bár ezek a csomagok csak töredéke a letöltötteknek, a nagyon rossz feltöltés/letöltés arány miatt már ez is elviheti a feltöltési sávszélességed nagyrészét.
    Ezen igazából csak a fel/le arány javítása segítene azaz egy jobb technológia.
    Mindenesetre a kicsi feltöltési sávszél jó eséllyel teljesen mindig megvan mint a nagyobb. Kérdés, hogy ez vigasztal-e.

    Persze ha csak annyi a feladat, hogy az elérhető sávszélességet kell arányosan elosztani az még mindig megoldható. Persze kérdés hogy egy rosszul beállított forgalomszabályozás ami egy nagyobb éjszakai letöltést megnyújt nappalra vagy még rosszabb esetben estére jó üzlet-e.

    Ebben a témában még bőven lehetne eszmecserélni, most ennyi jutott hirtelen eszembe.

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