Költség-hatékony sávszélesség-elosztás egy inheterogén hálózatban,

avagy

a sávszélesség nem mindig kevés

Erdélyi Gábor

Nagy Elemér Károly

1. A peremfeltételek:

Adott egy kollégiumi hálózat, 300 felhasználóval, akik különböző képzésekre járnak:

-Mindegyikük maga tartja karban a munkállomását, inhomogén szaktudással

-Viselkedésük és érdeklődésük (a használt szoftverek) szintén inhomogének

-Mivel külöböző egyetemekre/főiskolákra járnak, homogén fegyelmezésük gyakorlatilag lehetetlen.

Adott egy 4Mbps full duplex mikrohullámú kapcsolat (gyakori csomagvesztés) feletti tunnel (még gyakoribb csomagvesztés). A késleltetési idő alacsony kihasználtság esetén is viszonlyag nagy, magas kihasználtság esetén (az elveszett csomagok ismétlése miatt) nagyon nagy. A kapcsolat - anyagi okokból - igen nehezen bővíthető.

2. A probléma:

A problémát a túlterhelésből adódó hatalmas késleltés (0.5-7 másodperc) okozta. Ez az interaktív alkalmazások (távoli shell használata, NEPTUN használat, interaktív kommunikációs programok) használatát gyakorlatilag lehetetlenné tette, és szinte minden alkalmazás használatát kényelmetlenné tette. A prodzsekt célja tehát a késleltetés 0.2 másodperc alá csökkentése.

3. Az elméleti megközelítések:

0-100% kihasználtság(K) alatt a késleltetés C+A*K formában modellezhető, ahol A kicsi, azaz a konstans késleltetés alig nő. 100% kihasználtság felett (értem ezalatt azt, hogy ha az igények 4Mbps felett vannak) azonban túlterhelés miatt a sok elveszett csomag ismétlése miatt a késleltetés C+B*K formában modellezhető, ahol B igen nagy.

A háromszáz felhasználó modellezése még durva közelítéssel is gyakorlatilag lehetetlen. Ezért a modellezésre az egyszerű felhasználó modelljét (egész nap konstans terhelés, nincs szórás) használtuk.

4 Mbps jut a háromszáz felhasználóra, azaz egy felhasználóra (4*1024/300) körülbelül 13 Kbps jut. Ez tulajdonképpen a legtöbb alkalmazásra elég, ha a késleltetés nem túl nagy. Mivel a legtöbb felhasználó ezt nem használja ki, a napi limit (60*60*24*13*1024/8=137 MB) betartatása esetén praktikusan a hálózat leterheltsége 20%-90% között van.

4. A gyakorlati eredmények:

A limitet néhány nap mérés után 256MB-re növeltük, hogy a sebesség-kihasználtság optimumot megtaláljuk. A késleltetés a várt 0.005-0.1 másodperc tartományba esett. Körülbelül háromszáz ember jutott így jól használható hálózathoz.

5. A hatás:

Néhány nap után azt tapasztaltuk, hogy a felhasználók nagy része örült a változásoknak, ők az egészből csak annyit vettek észre, hogy "a hálózat gyorsabb lett". Néhány olyan felhasználó, akik a limitet sokszorosan túllépték (tipikusan mániákus szoftver-gyüjtögetők), nagyon hangosan és nagyon határozottan léptek fel a limit ellen, még akkor is, ha arányuk csak néhány százalék körül mozgott, és tisztában voltak vele, hogy mások kárára élik ki szenvedélyüket. A prodzsekt tehát sikeres volt.

6. Továbbfejlesztési lehetőségek:

További finomitást lehetne elérni a csúcsidőszak / nem csúcsidőszak bontással, azonban ez negatív pedagógiai hatást gyakorol (hajnali illetve délelötti hálózat-használat). Másik alternatíva a kihasználtságtól függő forgalom-számolás, azonban erre jelenleg praktikusan nincs szükség, és bonyolultságban messze felülmúlja a jelenlegi rendszert. Praktikusan javítaná a rendszer üzembiztonságát, ha a limit túllépése esetén a felhasználó szoftveresen kitiltódna, és nem kellene hardveresen korlátozni a hozzáférést. Ehhez a szükséges megbízható hardver-komponenseket várhatóan 2003 első félévében fogjuk beszerezni.

7. Tanulságok:

A népszerű idézettel ("A sávszélesség mindig kevés") ellentétben kijelenthetjük, hogy a sávszélesség a felhasználók nagyrészének (75-95%) elég, ha nem hagyjuk, hogy a felhasználók maradéka elhasználja előlük. Amennyiben nincsen valamilyen korlátozás, a sávszélesség a felhasználók igen kis részének elég (5-25%).

8. Technikai részletek:

A forgalom figyelését egy linuxos, szervernek kinevezett gép (PII-400) végzi, amelyben három hálózati kártyára van tükrözve a kimenő-bemenő illetve belső-proxy-külső forgalom. A forgalmat tcpdump segítségével egy-egy csővezetékekbe töltjük, amiből óránkénti bontásban egy C program szövegfájlokba rakja. A szövegfájlokat néhány AWK szkript dolgozza össze óránkénti, napi, heti, illetve csúszóablakos 31 napos CVS fájlokba, amit egy másik AWK szkript html fájlokba alakít, majd ezekből egy index html fájlt készít. A másik alternatíva egy adatbázis alapuló aktív html lapos szerver lett volna, azonban a megvalósítás egyszerűsége miatt nem ezt választottuk.