Sávszélesség korlátozása - nagyon!

 ( tovis | 2012. november 19., hétfő - 14:38 )

Széles sávú GSM kapcsolattal kísérletezgetek. Jó Lenne ha az ethrenet kapcsolatot tudnám lebutítani akár 9600 baud -nak megfelelő sebességig. Van erre valami megbízható módszer?
Debian Squeeze -t használok. Gondoltam arra is, hogy ppp -n keresztül csinálom, ott mintha alapból megadhatnám a sebességet, de hátha van valami egyszerűbb módja.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

valamilyen routert betenni és azon keresztül korlátozni?

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

+1
avagy ebtables+packetmark es mark alapjan tc

Valójában, egy olyan gépen lóg aminek két hálókártyája van, és így másik szegmens a LAN -on. Mitől jobb a router?
Az egyszerű, kommersz routerek nem igen tudnak sebességet korlátozni, vagy még nem találkoztam ilyen szerkezettel.

* Én egy indián vagyok. Minden indián hazudik.

.

általában minden filléres vacakban van már bandwidth management - vagy te még nem találkoztál ilyen szerkezettel?

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

nekem amikor kis sávszélességgel kellett tesztelnem cuccot, akkor a Cisco routeremhez kapcsolatam egy gépet soros porton és azon keresztül kapcsolódtam az Internethez. Persze nálam eleve ott volt a hálózatban a Cisco, így ez bőven leegyszerűsítette a dolgot.

+1, nullmodem kábellel, soros porton összedrótozni egy másik géppel, aztán ppp-t rá, és hajrá.

Kösz! De ez sajnos nem az ami nekem kell :(
A GSM átvitel nem priorál, ez vagy ennyi vagy annyi esetleg szakadozik stb. Tekintet nélkül arra hogy milyen protokoll működik.
Lehet hogy marad a ppp? - ott a szerver meghívásakor, előre megmondhatod mekkora is lehet a sebesség. Szerintem ez nem változik.

* Én egy indián vagyok. Minden indián hazudik.

tc+iptables? vagy kész megoldásként erre ott a shorewall (bár, hmm, gsm-mel még sose volt dolgom)
--
"'The time has come,' the Walrus said"

Itt a kütyü amivel piszmogok a gsm -ről mit sem tud. Egy belső ethernet "hálóban" van aminek a kapcsolata egy GSM router. A kütyü csak annyit érez, hogy lassú, szakadozó a kapcsolat. Nehezen "éled" - azaz eleinte roppant lassan mennek a csomagok :(

* Én egy indián vagyok. Minden indián hazudik.

shaperd alkalmas erre

Ígéretes! Kösz!

* Én egy indián vagyok. Minden indián hazudik.

A GSM/GRPS/EDGE és nagyobbakon a késleltetés más és más lesz, sőt ahogy váltja a módokat ingadozni is fog. Ezt is számold bele, ne csak a sávszélt.

Jó gondolat, de megvalósítást nem igen látom ... véletlenszerűen változtatni a sávszélt, plusz a késleltetést.

* Én egy indián vagyok. Minden indián hazudik.

Azt énsem látom sima etherneten, ez benne a kihívás. :)

[dupla]

Jól értem, hogy GSM "minőségű" IP kapcsolatot akarsz szimulálni tesztkörnyezetben..?

Mert akkor egyrészt netem qdisc, fölé pedig TBF, ami korlátozza a maximálisan elérhető sávszélt. Az elérhető maximális sávszélesség ingadozását szimuláld generált (meddő) forgalommal, az a legegyszerűbb. A leszakadásokat/újracsatlakozásokat pedig ebtables/iptables DROP-al. :)

Szerintem célszerű több apró scriptet írni, ami random sleep után változtat 1-1 jellemzőn, pl a meddő forgalom mennyiségén vagy épp beiktat egy újracsatlakozást, aztán fussanak párhuzamosan.

Ez a helyes irány szerintem is, bár én HTB-t javasolnék.
Mégpedig úgy, hogy 5 - 10 eszközt használsz (program, másik aktív eszköz, stb) a limitert beállítod úgy hogy a parent limiter adja a maximális sebességet (ceil,rate) mindegyik eszköznek az utolsó ág pedig szabályozza a maximális sebességet a benne lévő qdisc a delayt és a csomagvesztést.
Így a sebesség a legfelső ágban garantált és megegyezik az egyes ágak összsebességével (rate, ceil), a HTB leaf-ek maximált sávszélességet pedig az adott eszköz számára megadott (és egyben priorizációra használt) saját sebességét állítod, figyelj rá hogy a HTB 2 priorizációt használ, egyrészt van egy prio paramaméter amivel változtathatod az egyes ágak egymáshoz való viszonyát (célszerű most nem használni), másrészt a rate paraméter ami alapján az egyes gyerek ágak egymás között osztozkodnak a szülő ág maradék sávszélességén. Így megfelelő számú párhuzamos ág beléptetésével áganként azonos rate paraméter beállítása esetén egyszerűen shell script szintjén tudsz forgalom generáló klienst indítani/leállítani amivel szimulálható a változó elérés és CS váltás. A szimulált környezet legalsó HTB leaf-jére célszerű berakni a netem modult amivel szimulálható a delay és a csomagvesztés.
A default forgalmat beküldöd az így előállított node-ba filterrrel pedig beállítod az egyes ágakra a mérést segítő statisztikai programokat.
( pl: tc filter add dev lo protocol ip parent 1: prio 1 u32 match ip src 10.10.10.1 match ip dport 81 0xffff flowid 1:101 ahol a flowid paramétert változtatod 101-104-ig a src ip vagy esetleg csak a ip dport -ot változtatva) hogy a megfelelő ágba kerüljenek ezek a tesztforgalmazó eszközök amelyeket vagy elindítasz vagy nem.
A HTB szabályzási paramétere a quantum amit automatikusan állít, viszont extrém sebességeknél nagy ingás lehet, tehát lehet hogy ezt meg kellene adni. Default (kezdő) értéke 10, ha komolyan gondolod a 9600-at akkor az r2q-t célszerű 1-re venni.
Ami még gondot okozhat: MTU a választott átviteli eszközön (lehet célszerű lenne állítani, egyelőre nem tudok tanácsot adni) valamint az adott gép HZ értékét célszerűen 1000-re illene állítani
Sajnos a HTB-t sem használtam ilyen sebességű osztásra, és azt gondolom a 9600 nem is komoly cél, ezért én eleve nagyobb sávszélességű példát írnék...

pl: (feltételezve egy GPRS kapcsolatot 12kbps garantált sebesség limitálás maximum 57.6kbbs 5 ágban ezért a szülő rate 60k a ceil 288k az r2q ez esetben 1 lenne célszerűen a példában nem említve)

(a loopback interfész csak azért, mert az biztos van és teszt)
tc qdisc add dev lo root handle 1: htb default 100
tc class add dev lo parent 1:1 classid 1:10 htb rate 60kbps ceil 288kbps
tc class add dev lo parent 1:10 classid 1:100 htb rate 12kbps ceil 57600bps
tc class add dev lo parent 1:10 classid 1:101 htb rate 12kbps ceil 57600bps
tc class add dev lo parent 1:10 classid 1:102 htb rate 12kbps ceil 57600bps
tc class add dev lo parent 1:10 classid 1:103 htb rate 12kbps ceil 57600bps
tc class add dev lo parent 1:10 classid 1:104 htb rate 12kbps ceil 57600bps
tc qdisc add dev lo parent 1:100 netem delay 1000ms 600ms distribution normal

Így ha mind az 5 progi fut ami a 101 -104 ágat kiterheli akkor a 100 ágban a sebesség 12kbps lesz ha 4 progi fut akkor 12000+57600/4 ha három akkor 12000+115200/2 az egyes ágak maximális sebessége. Megfelelően nagy számú ággal precizebben állítható az aktuális elérhető sebesség. Illetve választhatsz az ágakban eltérő rate értéket (pl 24kbps a 12kbs helyett ilyenkor a szülő megmaradt sebességéből a rate arányában osztva elv szerint kapnak az ágak sebességet, bár ugye ez is csak a max elérhető sebesség arányát változtatja az egyes ágakon, de játékra jó, talán realisztikusabb is lehet.
A netem és a HTB doksiját célszerű átnézni és persze a puding próbája az evés, valamint a latency eloszlására választott disztribúcióra akár saját táblát bevezetni, vagy a 2 másik beépítettet használni.
Még pár apróság: sztem a mai 2G/3G csomagkapcsolt hálózatok sebessége nagyobb ennél 50k rate és 1400kbs-5Mbps ceil rate, ami változik a 50k és a 1400k között a sebesség nagyon ingadozik. Valamint a protokoll sajátossága miatt sok a veszteség (amikor 0 a sebesség) ezt a netem qdisc. tudja szimulálni kombinálható a delay és a loss aminek a párhuzamos megadása vagy egymás alatti diszciplínák használata is más eredményt adhat.
Véleményem szerint érzetre nem fogod tudni megközelíteni a 3G hálózati forgalmat, max statisztikailag jársz közel. Szóval a cél ha ismert akkor lehet azt mondom nem érdemes vele foglalkozni.... Az eredeti PPP felvetéshez képest szerintem túl sok erőbefektetés és elég lenne 1 db ág és a netem modul loss és delay meg gap paraméterei bár az a jelminőség változást illetve a párhuzamos forgalmat abszolút nem szimulálja. :)

Hát ez tényleg nem tűnik egyszerűnek.
A lényeg hogy valami megközelítő szimuláció legyen és alapvetően két dolgot látok: sávszélesség és látencia (vagyis amikor kapcsolódik valahova akkor eleinte lassú, majd kicsit "összekapja magát", ez fordítva is így lehet).

* Én egy indián vagyok. Minden indián hazudik.

> amikor kapcsolódik valahova akkor eleinte lassú, majd kicsit "összekapja magát"

Ez a TCP slow-start. Elég magas késleltetést emulálni és megfigyelhető ugyanez a jelenség (tulajdonképpen mindenhol megfigyelhető, csak alacsony késleltetés esetén hamar lezajlik felfutás).

Ott van neked a Dummynet, ami pontosan erre van kitalalva. Eredetileg FreeBSD-s, de ott a linuxos (meg a Windows-os) verzio a letoltesnel.
http://info.iet.unipi.it/~luigi/dummynet/

Valoszinuleg atomtamadas verebre, de azert erdemes lehet megnezni (van demo/trial verzio is): http://www.candelatech.com/

wondershaper [interface] [downlink] [uplink]
Debian csomag :)

szerk.:
Ups. én is csak írok, nem olvasok :(

nezgulj, én is csak "vaktában" írtam. Nem volt időm olvasgatni, de a legegyszerűbb dolog jutott az eszembe nekem is először. Mert minek bonyolítani a dolgokat..

Hogy legyen egy igazan overkill megoldas is: vmware workstation. Beepitetten tud kulonbozo savszelessegeket emulalni, fix paket losszal.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

+1

iptablessel is lehet, de még nem csináltam, olvaastam valahol róla. Talán pont itt