Költség-hatékony
sávszélesség-elosztás egy inheterogén hálózatban,
avagy
a sávszélesség nem mindíg
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.