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

• #4 chros őstag bambano #2

  Új Válasz 2016-06-01 22:41:30 #4

  Ú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

  

  chros

  őstag

  válasz bambano #2 üzenetére

  "az upload korlátozás azért egyszerű, mert nem lehet rendesen korlátozni, csak tranzitíven. ezt az is alátámasztja, hogy az elsőként linkelt lapon sem a bemenő interfészen korlátoznak, hanem a kimenőn."
  Bocs, de ezt egyaltalan nem ertem.
  Ezt nem a kimenon kene? (a peldaban eth1 a kimeno interface)

  "a download korlátozás működik rendesen."
  Hogyan, ebben a peldaban?
  simple.qos -t hasznalva: "The 3 band up and down separation is mostly on IP header attributes for QOS (DSCP field), which may or may not be used in client software. It does less with protocol/port."
  Ha jol ertem, akkor hasnlo dolgot kell csinalni az ingress-ben az alap 3-tier classification-nal: kiboviteni 4-re:
  +BL_RATE=`expr $CEIL / 2` # let's half the connection bandwidth
  +$TC class add dev $IFACE parent 1:1 classid 1:14 htb $LQ rate ${BL_RATE}kbit prio 4 `get_htb_adsll_string`
  +$TC qdisc add dev $IFACE parent 1:14 handle 140: $QDISC `get_limit ${ELIMIT}` `get_target "${ETARGET}" ${DOWNLINK}` `get_ecn ${EECN}` `get_quantum 300` `get_flows ${BL_RATE}` ${EQDISC_OPTS}

  Es a police filter-t nem latom, hova kene beilleszteni, itt mashogy epitkezik, mint az egress eseteben.
  Es az iptables sor hogyan nezne ki ebben az esetben?

  "Én próbáltam régebben összerakni, hfsc, és ingress schedulerekkel a qos scripts alapján,"
  En viszont szivesebben latnam az sqm scriptek egyeket (vagy akar 2-t vagy mindet ) modositva, s ezzel elvezve minden elonyet: [link] . Mar csak azert is, mert ezeket mar megirtak a hozzaertok, s csak "kicsit" kell rajta valtoztatni (lasd lentebb).

  Mint a fenti linkekebol kiderul, a kulonbozo queue scriptek egyaltalan nem azonos alapokra epitkeznek, s masra vannak kitalalva. Pl. [link]
  Az alapotletben simple.qos -t hasznalnak, de hosszu tavon nekem a hfsc_lite.qos tetszene (ez hasonlit leginkabb az eddig hasznalt sima QoS-re OpenWRT-bol).

  Eloszor simple.qos-t kene kitalalni, probakeppen (ez tunik egyszerubbnek). Lasd fentebb.

  I. Eric otlete lepesekre bontva:
  1. "Lets assume we only want to control access to the WAN for a host, and leave local communication alone."
  2. "Generically (cake or no), there could be a way to assign a subclass shaper with its own qdisc"
  3. "and filter on IP (tc filter ~ u32 match src / dst) or MAC through contrack.
  4. "A generic functions.sh subroutine would need to have the shaper as a parameter and know how to handle each shaper. The qdisc is already a dynamic option. As long as all scripts followed class numbering convention, this could be a plugin for all of them from functions.sh."
  5. "It gets ugly fast though. CPU load for each class ingress and egress."
  6. "IPV4 address white/black list from DHCP is easy. But IPV6 has so many permutations."
  7. "So you can only have a single router so that contrack can hold the mac addresses."

  Nezzuk, ami jonak tunik:
  - 1. , 7.
  - 6. : IPV6-tal nem kell belulrol foglalkoznunk, de ez mar csak kozmetika a vegen
  - 5. : ez sem tunik nagy gondnak, altalaban 1-2 szabalyra lenne szukseg (nekem pl. 1 ingress es 1 egress boven eleg: az mas kerdes, hogy lehet, hogy ez nem csak 2, hanem akar 6 is az adott queue scriptben implementalva; nem tudom)

  Es ami macera:
  - 2. : ezt kene jol kitalalni minden queue scriptre (vagy parra) , es ez a legnagyobb problema
  - 3. : ezt konnyu scriptelni szamunkra kesobb akar a ti webes feluleteteken
  - 4. : erre nincs szuksegunk, most ugy gondolom (legalabb is az elejen)

  Igy, ha jol ertem, "csak" a 2. pont a kerdes, de az erosen.

  Ha egyetertetek ezzel, akkor csinalok egy git repot ehhez, s megkezdothet a kiserletezes. (Es abban is biztos vagyok, ha mar van feleksz/kesz kod, akkor a guruk is reneznek majd az sqm-sripts projectbol, s segitenek benne.)

• #3 Headless őstag chros #1

  Új Válasz 2016-06-01 14:21:31 #3

  Ú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

  

  Headless

  őstag

  válasz chros #1 üzenetére

  Hát én úgy gondolom az alapokhoz kéne visszamennünk... vagyis a tc-hez, amit az összes ilyen script használ...

  [link]

  Én próbáltam régebben összerakni, hfsc, és ingress schedulerekkel a qos scripts alapján, de nem jutottam sokra, ezért inkább azzzal a schedulerrel kéne megpróbálni, ami direkt a fix korlátozásra van, vagyis a "Token Bucket Filter"-el viszont ez nincs benne a "kmod-sched-core"-ban. hanem a sima "kmod-sched"-et kéne felrakni.

  Ha a korlátozás rész megvan utána már csak a filtert kell kitalálni, amihez openwrt oldalon is van segítség... És ha már felépítettük a rendszert, akkor már csak egy lépés egy közérthető webes felületet csinálni hozzá...

• #2 bambano titán chros #1

  Új Válasz 2016-06-01 14:12:31 #2

  Ú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

  

  bambano

  titán

  válasz chros #1 üzenetére

  az upload korlátozás azért egyszerű, mert nem lehet rendesen korlátozni, csak tranzitíven. ezt az is alátámasztja, hogy az elsőként linkelt lapon sem a bemenő interfészen korlátoznak, hanem a kimenőn.

  a download korlátozás működik rendesen.

• #1 chros őstag

  Új Válasz 2016-06-01 13:21:09 #1

  Ú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

  

  chros

  őstag

  Szoval: [link]
  Elsodlegesen quota support-tal nem kell foglalkozni.
  Az upload korlatozas tul egyszerunek tunik.
  Es a download-ot sem ertem nagyon

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