Piszemy skrypty QOS: HFSC, IMQ - HOWTO

W tym miejscu zapraszamy Was do współpracy. Czekamy na propozycje, sugestie i rady.
Moderatorzy zatroszczą się o to, by najlepsze teksty trafiły do FAQ.

Moderatorzy: Moderatorzy, Administratorzy

luckyluk
Użytkownik
Posty: 1
Rejestracja: 2007-11-09, 13:59

Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: luckyluk »

Witam,

Mam zadanie na studiach, napisać skrypty QOS z podziałem na usługi i userów,
dla najczęściej spotykanych łącz dla małych ip, czyli coś około DSL 1 - 4 mb,
czy tez NEO i co tam niepopadnie jest stosowane.

Jako że nie jestem samolubem postanowiłem zrobić przy okazji HOWTO i udostępnić je w necie dla potomnych, aby nie musieli się już później męczyć tak jak ja.

Dużo takich skryptów w sieci już lata, ale trudno dogrzebać się czegoś z równoczesnym podziałem na userów i usługi, a zwlaszcza zeby bylo dobrze opisane.
Usługi chciałbym zmarkować za pomocą layer7 a nie po portach, bo wiadomo jacy userzy są (Ale o tym dalej).

Znalazlem już coś w sieci, ale jest to zrobione za pomocą filtrów po portach.

Proszę więc wszystkich którzy posiadają pomocną wiedzę w udziale w powstaniu HOWTO, oraz o sprawdzenie dotychczasowej pracy.
Wszelkie komentarze są mile widziane, tym bardziej że na HFSC mało się znam wcześniej lizniete mialem cos o htb.

Poniżej zaprezentuje co już posiadam. (większość w oparciu o skrypt Rafała Rajsa)


Plik ze zmiennymi (łącza, ip userów itp): rc.zmienne

Problem, czy ustawiać 90% lacza tak jak sie robilo w htb ?

Kod: Zaznacz cały

#!/bin/sh

# definiujemy interfejsy
ZEW=eth0 #publiczny do neta
WEW=eth1 #wewnetrzny LAN do lodkow

LAN="192.168.2.0/24"	# klasa lan
IP_ZEW="83.13.131.61"	#ip publiczne

# upload i download lacza
NET_DOWNLOAD=4096
NET_UPLOAD=512

# wylicz 90% ze wzgledu na opoznienia (czy dobry zapis ??)
MAX_DOWNLOAD=$[$NET_DOWNLOAD*90/100]
MAX_UPLOAD=$[$NET_UPLOAD*90/100]

MARK_START=0
MAX_RESERVE=20

# to moze pozniej wykorzystam do ograniczenia liczby polaczen na wysokich portach
MAX_CONNS=40

###


L_USERS=3 # liczba userow + serwer

#user 1
USER_IP[1]="10.1.1.50"
#user 2
USER_IP[2]="10.1.1.60"
#serwer
USER_IP[3]=$IP_ZEW 

###

IPTABLES=iptables
TC=tc
[/code]

Plik z skryptem hfsc: rc.hfsc

Kod: Zaznacz cały

#!/bin/sh
. ???/rc.zmienne # zmienic ??? na lokalizacje pliku


###
#download do imq0
TCQ_D="$TC qdisc add dev imq0"
TCC_D="$TC class add dev imq0"
TCF_D="$TC filter add dev imq0 parent 1: protocol ip"

#upload do imq1
TCQ_U="$TC qdisc add dev imq1"
TCC_U="$TC class add dev imq1"
TCF_U="$TC filter add dev imq1 parent 1: protocol ip"


#czyszczenie kolejki
#$TC qdisc del root dev imq0 
#$TC qdisc del root dev imq1

#dodajemy glowne kolejki 
$TCQ_D root handle 1: hfsc default 500 
$TCQ_U root handle 1: hfsc default 500 
co oznacza default 500 ?

Kod: Zaznacz cały

# download
$TCC_D parent 1: classid 1:1 hfsc sc rate ${MAX_DOWNLOAD}kbit ul rate ${MAX_DOWNLOAD}kbit 

# upload
$TCC_U parent 1: classid 1:1 hfsc sc rate ${MAX_UPLOAD}kbit ul rate ${MAX_UPLOAD}kbit 

#default reserve queue
$TCC_D parent 1:1 classid 1:500 hfsc sc rate ${MAX_RESERVE}kbit ul rate ${MAX_RESERVE}kbit 
$TCC_U parent 1:1 classid 1:500 hfsc sc rate ${MAX_RESERVE}kbit ul rate ${MAX_RESERVE}kbit 


# download dla usera
USER_UPLOAD=$[$MAX_UPLOAD/($L_USERS+1)]

# upload dla usera
USER_DOWNLOAD=$[$MAX_DOWNLOAD/($L_USERS+1)]


# podklasy z podziałem: 55% ruch wazny, 25% reszta ()

USER_D_PRIOR=$[$USER_DOWNLOAD*55/100]
USER_D_RESZTA=$[$USER_DOWNLOAD*25/100]

USER_U_PRIOR=$[$USER_UPLOAD*55/100]
USER_U_RESZTA=$[$USER_UPLOAD*25/100]
1.moglby byc podzial na trzy klasy wazny/reszta/p2p
2.czy % nie powinny sie sumowac do 100 ?

Kod: Zaznacz cały

#numery podklas
N_CLASS_D=10
N_CLASS_U=40

N_CLASS_D_1=70
N_CLASS_D_2=100
N_CLASS_U_1=130
N_CLASS_U_2=160

N_CLASS_D_1_Q=190
N_CLASS_D_2_Q=220
N_CLASS_U_1_Q=250
N_CLASS_U_2_Q=280

i=1
j=1


#dla kazdego usera w petelce
while [ $i -le $L_USERS ]
do

  #ograniczenie userow na IP
  $TCC_D parent 1:1 classid 1:$[$N_CLASS_D+$i] hfsc sc rate ${USER_DOWNLOAD}kbit ul rate ${MAX_DOWNLOAD}kbit #1 user
  $TCC_U parent 1:1 classid 1:$[$N_CLASS_U+$i] hfsc sc rate ${USER_UPLOAD}kbit ul rate ${MAX_UPLOAD}kbit #1 user

  # podzielic to na kolejne dwie klasy. Maksymalne opoznienie w waznej klasie! (prosze sprawdzic czy dobry zapis, komentarze porządane)
  #download
  $TCC_D parent 1:$[$N_CLASS_D+$i] classid 1:$[$N_CLASS_D_1+$i] hfsc sc umax 1500b dmax 20ms rate ${USER_D_PRIOR}kbit ul rate ${MAX_DOWNLOAD}kbit # wazne
  $TCC_D parent 1:$[$N_CLASS_D+$i] classid 1:$[$N_CLASS_D_2+$i] hfsc sc rate ${USER_D_RESZTA}kbit ul rate ${MAX_DOWNLOAD}kbit #reszta
  #upload	
  $TCC_U parent 1:$[$N_CLASS_U+$i] classid 1:$[$N_CLASS_U_1+$i] hfsc sc umax 1500b dmax 20ms rate ${USER_U_PRIOR}kbit ul rate ${MAX_UPLOAD}kbit # wazne
  $TCC_U parent 1:$[$N_CLASS_U+$i] classid 1:$[$N_CLASS_U_2+$i] hfsc sc rate ${USER_U_RESZTA}kbit ul rate ${MAX_UPLOAD}kbit # reszta
  
  # fifo dla waznych, sfq dla reszty (www i fifo nie pasuje stad 3 klasy porzadane, perturb to priorytet ?)
  $TCQ_D parent 1:$[$N_CLASS_D_1+$i] handle $[$N_CLASS_D_1_Q+$i]:0 pfifo
  $TCQ_D parent 1:$[$N_CLASS_D_2+$i] handle $[$N_CLASS_D_2_Q+$i]:0 sfq perturb 10
  $TCQ_U parent 1:$[$N_CLASS_U_1+$i] handle $[$N_CLASS_U_1_Q+$i]:0 pfifo
  $TCQ_U parent 1:$[$N_CLASS_U_2+$i] handle $[$N_CLASS_U_2_Q+$i]:0 sfq perturb 10




  #ruch kazdego usera kieruj do odpowiednich kolejek

  #upload waznego ruchu dla usera ( mozna dodac SSH, WWW, CS etc)
  $TCF_U prio 3 u32 match ip protocol 1 0xff match ip src ${USER_IP[${i}]} flowid 1:$[$N_CLASS_U_1+$i]
  $TCF_U prio 3 u32 match ip sport 22 0xffff match ip src ${USER_IP[${i}]} flowid 1:$[$N_CLASS_U_1+$i]
  $TCF_U prio 3 u32 match ip dport 22 0xffff match ip src ${USER_IP[${i}]} flowid 1:$[$N_CLASS_U_1+$i]
  $TCF_U prio 3 u32 match ip sport 53 0xffff match ip src ${USER_IP[${i}]} flowid 1:$[$N_CLASS_U_1+$i]
  $TCF_U prio 3 u32 match ip dport 53 0xffff match ip src ${USER_IP[${i}]} flowid 1:$[$N_CLASS_U_1+$i]

  #upload ogolny
  $TCF_U prio 20 u32 match ip src ${USER_IP[${i}]} flowid 1:$[$N_CLASS_U_2+$i]
  

  #download waznego ruchu dla usera ( mozna dodac SSH, WWW, CS etc)
  $TCF_D prio 2 u32 match ip protocol 1 0xff match ip dst ${USER_IP[${i}]} flowid 1:$[$N_CLASS_D_1+$i]
  $TCF_D prio 2 u32 match ip sport 22 0xffff match ip dst ${USER_IP[${i}]} flowid 1:$[$N_CLASS_D_1+$i]
  $TCF_D prio 2 u32 match ip dport 22 0xffff match ip dst ${USER_IP[${i}]} flowid 1:$[$N_CLASS_D_1+$i]
  $TCF_D prio 2 u32 match ip sport 53 0xffff match ip dst ${USER_IP[${i}]} flowid 1:$[$N_CLASS_D_1+$i]
  $TCF_D prio 2 u32 match ip dport 53 0xffff match ip dst ${USER_IP[${i}]} flowid 1:$[$N_CLASS_D_1+$i]

  #download ogolny dla usera
  $TCF_D prio 30 u32 match ip dst ${USER_IP[${i}]} flowid 1:$[$N_CLASS_D_2+$i]
### zamiast tego co powyzej chcialbym uzyc marka z layer7 czyli moze dla upload:
# tc filter add dev imq1 parent 1: protocol ip prio 1 handle $[$MARK_START+$j] fw classid 1:$[$N_CLASS_U_1+$i] # ruch wazny
# tc filter add dev imq1 parent 1: protocol ip prio 5 handle $[$MARK_START+$j+1] fw classid 1:$[$N_CLASS_U_2+$i] # ruch ogolny

#regolki iptables beda nizej

Kod: Zaznacz cały

 # j juz chyba niepotrzebne chyba ze do zakomentowanej propozycji z wartoscia +2
  j=$[$j+4]

  i=$[$i+1]
done
tak moglyby wygladac regolki iptables do markowania (mam nadzieje ze dobrze):
i=1
j=1

while [ $i -le $L_USERS ]
do
MARKOWANIE pakietow!
upload ogolny dla usera
$IPTABLES -t mangle -A POSTROUTING -o $ZEW --src ${USER_IP[${i}]} -j MARK --set-mark $[$MARK_START+$j+3]
#przemarkuj upload wazny
$IPTABLES -t mangle -A POSTROUTING -o $ZEW -m layer7 --l7proto ssh --src ${USER_IP[${i}]} -j MARK --set-mark $[$MARK_START+$j+2]
$IPTABLES -t mangle -A POSTROUTING -o $ZEW -m layer7 --l7proto dhcp --src ${USER_IP[${i}]} -j MARK --set-mark $[$MARK_START+$j+2]
$IPTABLES -t mangle -A POSTROUTING -o $ZEW -m layer7 --l7proto dns --src ${USER_IP[${i}]} -j MARK --set-mark $[$MARK_START+$j+2]

i=$[$i+1]
j=$[$j+2]
done;

Kod: Zaznacz cały

# przekieruj ruch z lacza zewnetrznego do imq:
$IPTABLES -t mangle -A POSTROUTING -o $ZEW -j IMQ --todev 1 #upload
$IPTABLES -t mangle -A PREROUTING -i $ZEW -j IMQ --todev 0 #download

# podnies interfejsy imq
ip link set imq0 up
ip link set imq1 up
narazie tyle mam,
uprzejmie proszę o przyglądnięcie się kodzikowi i obkomentowanie, zwlaszcza propozycji.
// Ps. temat dałem też na innych forach
Awatar użytkownika
Sad Mephisto
Administrator
Posty: 2824
Rejestracja: 2004-05-22, 13:24
Lokalizacja: Zabrze
Kontakt:

Re: Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: Sad Mephisto »

Ciekawa lekturka. Przenoszę wątek do "Propozycji do FAQ". Przeczytaj proszę ten wątek i przystosuj tekst do wytycznych :)
[i]Thank you for noticing this notice. Now that you've noticed this notice, you may have noticed that this notice is noticably unnoticable.
$ python -c "print int(''.join(map(lambda x: str(len(x)),'Kto z woli i myśli zapragnie Pi spisać cyfry ten zdoła.'.split())))/1e+10"[/i]
Awatar użytkownika
ondreyos
Użytkownik
Posty: 331
Rejestracja: 2007-11-01, 17:31
Lokalizacja: Poznań

Re: Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: ondreyos »

Problem, czy ustawiać 90% lacza tak jak sie robilo w htb ?
o ile sie orientuje, w wupadku hfsc nie jest to konieczne:
Podstawowa różnica między HFSC a HTB polega na zupełnie odmiennym traktowaniu ruchu nieprzypisanego do żadnej kolejki (w tym pakietów ARP). HTB samo tworzyło ukrytą kolejkę dla takiego ruchu i go przepuszczało, natomiast HFSC bez kolejki domyślnej albo z kolejką domyślną o bardzo małej wielkości, może odrzucać pakiety niesklasyfikowane. Odrzucanie pakietów ARP może powodować niedziałanie sieci, więc stosując HFSC należy koniecznie zadbać o dokładne klasyfikowanie ruchu i stworzenie domyślnej kolejki.
oczywiscie wazne jest, aby nie przydzielic wiecej, niz wynosi fizyczna/realna przepustowosc lacza, inaczej praktycznie cala idea kolejkowania na poziomie routera bierze w leb i znowu kolejki sie robia u providera.
Awatar użytkownika
xil
Moderator
Posty: 862
Rejestracja: 2004-06-20, 22:20
Lokalizacja: Białystok
Kontakt:

Re: Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: xil »

ondreyos pisze:
Problem, czy ustawiać 90% lacza tak jak sie robilo w htb ?
o ile sie orientuje, w wupadku hfsc nie jest to konieczne:
bzdura...
jest konieczne, a na pewno wskazane... zwlaszcza na dsl z wielka iloscia polaczen...

wysylanie traktowac ponizej jako download.
gorzej, przy ruchu max teoria 4mbit/s wysylamy 4000000 bitow/s, czyli 500 000 b/s
oznacza to, ze ramke 1500B (ethernetowa) wysylamy 333 razy na sekunde maksymalnie (i tak tak nie bedzie - to teoria).

co oznacza, ze jedna ramka o 1500B moze miec opoznienie minimalne rzedu: 3ms.

jesli zalozymy, jak w skryptach, ze max opoznienie dla ruchu priorytetowego wynosi 20ms, to mamy ok 7 klientow, po ktorych algorytm przejdzie w prace RT (real time), gdzie troche delikatnie potnie przydzialy dla reszty kolejek.
hfsc dziala zawsze probujac zapewnie RT dla kolejek. minimalny czas oczekiwany wygra z 'wirtualnym czasem', ktory nie bedzie w ogole brany pod uwage...
Ostatnio zmieniony 2007-11-11, 00:25 przez xil, łącznie zmieniany 1 raz.
Awatar użytkownika
xil
Moderator
Posty: 862
Rejestracja: 2004-06-20, 22:20
Lokalizacja: Białystok
Kontakt:

Re: Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: xil »

proponuje autorowi odpowiedziec na pewne 2 pytania:

Kod: Zaznacz cały

  $TCC_D parent 1:$[$N_CLASS_D+$i] classid 1:$[$N_CLASS_D_1+$i] hfsc sc umax 1500b dmax 20ms rate ${USER_D_PRIOR}kbit ul rate ${MAX_DOWNLOAD}kbit # wazne
co oznacza dmax 20ms ?

oraz:

Kod: Zaznacz cały

  # fifo dla waznych, sfq dla reszty (www i fifo nie pasuje stad 3 klasy porzadane, perturb to priorytet ?)
jesli autor uwaza, ze perturb to priorytet, to ja nie mam wiecej pytan....
Awatar użytkownika
xil
Moderator
Posty: 862
Rejestracja: 2004-06-20, 22:20
Lokalizacja: Białystok
Kontakt:

Re: Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: xil »

dodatkowo, nie uwazam, zeby nakladanie fifo na wazne polaczenia bylo dobrym rozwiazaniem, sfq wydaje sie o niebo lepszym dla koncowego usera!

zeby dopelnic miary, stosowanie jednego, wspolnego kryterium dla ruchu waznego i mniej waznego (dokladnie - ${MAX_DOWNLOAD} lub upload) jest z praktycznego punktu widzenia zlym podejsciem... znacznie lepiej jest dac mniejsza predkosc dla mniej waznego ruchu (brak efektu nasycenia - dostateczny zapas dla wrazliwego ruchu).
Awatar użytkownika
ondreyos
Użytkownik
Posty: 331
Rejestracja: 2007-11-01, 17:31
Lokalizacja: Poznań

Re: Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: ondreyos »

o ile sie orientuje, w wupadku hfsc nie jest to konieczne
[...]

xil napisal
bzdura...
jest konieczne, a na pewno wskazane...
pozwole sobie zaprotestowac. odnosisz sie do fragmentu wyrwanego z kontekstu. napisalem jeszcze miedzy innymi cos takiego:
oczywiscie wazne jest, aby nie przydzielic wiecej, niz wynosi fizyczna/realna przepustowosc lacza
wiec (przynajmniej tak ja to rozumiem) cale rozwazania o pakietowosci lacza, przepustowosciach itp nie sa w sprzecznosci z tym, co pisalem. poza tym przyklad lacza dsl'a nie jest idealny - mamy jeszcze wiele innych rodzajow laczy.

a piszac, ze przydzielanie 90% lacza nie jest konieczne mialem na mysli (co zreszta poparlem stosownym cytatem wyjasniajacym o co chodzi) inne podejscie htb/hfsc do pewnych rodzajow ruchu.

a zeby nie bylo, ze jestem taki 'na nie' ;)
dodatkowo, nie uwazam, zeby nakladanie fifo na wazne polaczenia bylo dobrym rozwiazaniem, sfq wydaje sie o niebo lepszym dla koncowego usera!
- z tym sie w 200% zgadzam.

pozdr.
Ostatnio zmieniony 2007-11-13, 16:48 przez ondreyos, łącznie zmieniany 1 raz.
Awatar użytkownika
xil
Moderator
Posty: 862
Rejestracja: 2004-06-20, 22:20
Lokalizacja: Białystok
Kontakt:

Re: Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: xil »

ondreyos pisze:
o ile sie orientuje, w wupadku hfsc nie jest to konieczne
[...]

xil napisal
bzdura...
jest konieczne, a na pewno wskazane...
pozwole sobie zaprotestowac. odnosisz sie do fragmentu wyrwanego z kontekstu. napisalem jeszcze miedzy innymi cos takiego:
oczywiscie wazne jest, aby nie przydzielic wiecej, niz wynosi fizyczna/realna przepustowosc lacza
wiec (przynajmniej tak ja to rozumiem) cale rozwazania o pakietowosci lacza, przepustowosciach itp nie sa w sprzecznosci z tym, co pisalem. poza tym przyklad lacza dsl'a nie jest idealny - mamy jeszcze wiele innych rodzajow laczy.

a piszac, ze przydzielanie 90% lacza nie jest konieczne mialem na mysli (co zreszta poparlem stosownym cytatem wyjasniajacym o co chodzi) inne podejscie htb/hfsc do pewnych rodzajow ruchu.
nie, to nie jest tak, 90% wcale nie wynika z tego, ze istnieje lub nie istnieje domyslna kolejka.... w wiekszosci skryptow i tak default bedzie ustawiony - bez wzgledu na to, czy jest to htb czy hfsc... i nie jest tez tak, ze to musi byc 90%.... rownie dobrze moze to byc 95% albo i 97% - zaleznie od sprzetu, ktorym sie dysponuje.
obnizona predkosc jest stosowana, zeby nie robily sie zatory na pierwszym routerze, ktory zazwyczaj obcina nam ruch do wybranej predkosci... z tym jest troche podobnie jak ze swapem (partycja) - jedni nie potrzebuja, inni nie wiedza ile ma wynosic, a jeszcze inni mowia, ze to 2x wielkosc ram. tak jest z tymi 90%/95%.
praktycznie jednak przy stosowaniu qos na linuksie warto zrobic jakis margines - czasem mniejszy czasem wiekszy - wszystko oczywiscie zalezy...
a zeby nie bylo, ze jestem taki 'na nie' ;)
dodatkowo, nie uwazam, zeby nakladanie fifo na wazne polaczenia bylo dobrym rozwiazaniem, sfq wydaje sie o niebo lepszym dla koncowego usera!
- z tym sie w 200% zgadzam.
pozdr.
Awatar użytkownika
ondreyos
Użytkownik
Posty: 331
Rejestracja: 2007-11-01, 17:31
Lokalizacja: Poznań

Re: Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: ondreyos »

no ale z grubsza chyba napisalem to samo :
oczywiscie wazne jest, aby nie przydzielic wiecej, niz wynosi fizyczna/realna przepustowosc lacza, inaczej praktycznie cala idea kolejkowania na poziomie routera bierze w leb i znowu kolejki sie robia u providera.
kwestia zapasu rzeczywiscie jest istotna - ale raczej na poziomie 2-4%, a nie 10 (oczywiscie zalezy od jakosci i stabilnosci lacza). a co do przydzielania 90% - sadzilem, ze pytajacemu chodzi o cos innego, co zreszta wyjasnilem w pierwszym poscie.

i mysle, ze nie ma sensu ciagnac tego tematu. moze sie troche nie dogadalismy, ale nie ma sensu dalej sobie tlumaczyc nawzajem to samo.
sph
Użytkownik
Posty: 19
Rejestracja: 2007-05-11, 14:31

Re: Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: sph »

Chciałbym podłączyć się do dyskusji, gdyż moje wypociny nie działają tak jakbym chciał.
Zaznaczam na początku ze to HTB a nie HFSC Chodzi o to, że postanowiłem zrobić podział ze względu na użytkowników, tego dokonałem na interfejsach eth0 i eth1, a na interfejsach IMQ (BA) podział ze względu na usługi.

Jeśli ktoś zechciałby rzucić okiem i pomóc.

http://forum.slackware.pl/viewtopic.php?t=18600
Ostatnio zmieniony 2008-02-28, 14:24 przez sph, łącznie zmieniany 1 raz.
Awatar użytkownika
xil
Moderator
Posty: 862
Rejestracja: 2004-06-20, 22:20
Lokalizacja: Białystok
Kontakt:

Re: Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: xil »

przepraszam, ale co ma propozycje do FAQ do konkretnego problemu ?
sph
Użytkownik
Posty: 19
Rejestracja: 2007-05-11, 14:31

Re: Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: sph »

Fakt. Troszkę niepasuje. Gdyż to dotyczy HTB a nie HFSC.
beblok
Użytkownik
Posty: 1
Rejestracja: 2008-03-29, 15:56

Re: Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: beblok »

a czy czasami nie brakuje tutaj wirtualnych interfejsow IMQ ? (interfejsow na ktorych tworzy sie kolejki wejsciowe) czy to moje nie dopatrzenie ?
Awatar użytkownika
xil
Moderator
Posty: 862
Rejestracja: 2004-06-20, 22:20
Lokalizacja: Białystok
Kontakt:

Re: Piszemy skrypty QOS: HFSC, IMQ - HOWTO

Post autor: xil »

beblok, a kto powiedzial, ze one sa potrzebne?

jesli serwer stoi i tylko przerzuca ruch i nic z niego nie jest pobierane (czyt. nie ma uslug na nim) to IMQ jest zbedne.
ODPOWIEDZ