Hi list!
I have a LAN server with Gentoo Linux. It''s a Pentium III at 1000 MHz
with 256 MB SDRAM.
I''ve implemented a QoS solution with HTB and SFQ.
Here is the diagram:
_______________________________________________________________________
1:--+----1:1 - [ counter-strike & icmp ] rate=1Mbit; ceil=1Mbit;
| prio 0; (u32 filter by ports)
|
|----1:2 - [ Internet ] rate=1.5Mbit; ceil=rate; prio 1;
| | (RNR=rate) RNR = Root iNet Rate
| |
| |---1:20 - [ normal traffic ] rate=90% of $RNR; ceil=$RNR;
| | prio 0; (u32 filter by ports)
| |
| \---1:21 - [ p2p traffic ] (default class) rate=1kbit;
| ceil=90% of $RNR; prio 1
|
|----1:3 - [ MAN ] rate=1Mbit; ceil=10Mbit-$RNR; prio 1
| | (RMC=ceil) RMC = Root MAN Ceil
| | MAN destinations are marked with 0x1 Marker
| |
| |---1:30 - [ normal traffic ]
| | rate=500kbit;ceil=($RMC-$RNR-1)kbit;
| | prio 0; (u32 filter by ports AND fw mark)
| |
| \---1:31 - [ p2p traffic ] rate=1kbit; ceil=($RMC-$RNR-1)kbit;
| prio 1; (u32 filter by fw mark)
|
\----1:4 - [ LAN ] rate=89Mbit; ceil=89Mbit
________________________________________________________________________
dev is eth0 and eth1; eth0 is connected at the Internet and eth1 is
connected at my LAN.
My problem:
when connecting from LAN to outside counter-strike servers i have a
280-1500 ms lag.
For counter-strike to be playable i need to have a lag of 0 to 65 ms.
If I tc qdisc del dev eth* root; i have a lag of 45 to 120 ms.
How can I improve response times? Has anyone any ideea? I can change the
server to a Pentium III at 1000 MHz with RIMM. Would that help?
Or is there a software solution?
Thank you in advance!
Sorin
Dnia czwartek, 2 marca 2006 12:45, Sorin Panca napisał:> Hi list! > > > How can I improve response times? Has anyone any ideea? I can change the > server to a Pentium III at 1000 MHz with RIMM. Would that help? > Or is there a software solution?You should use PRIO to divide traffic into 2 classes 1) ultra-critical ( here : cs game ) 2) other 3) very low prio ( more info is on voip-info.org , section : QoS under Linux ) you just have to mark CS packets and put them into the right PRIO class -- Jakub Wartak -vnull FreeBSD/OpenBSD/Linux/Solaris/Network Administrator vnull.pcnet.com.pl
On Thu, Mar 02, 2006 at 01:45:01PM +0200, Sorin Panca wrote:> _______________________________________________________________________ > > > 1:--+----1:1 - [ counter-strike & icmp ] rate=1Mbit; ceil=1Mbit; > | prio 0; (u32 filter by ports) > | > |----1:2 - [ Internet ] rate=1.5Mbit; ceil=rate; prio 1; > | | (RNR=rate) RNR = Root iNet Rate > | | > | |---1:20 - [ normal traffic ] rate=90% of $RNR; ceil=$RNR; > | | prio 0; (u32 filter by ports) > | | > | \---1:21 - [ p2p traffic ] (default class) rate=1kbit; > | ceil=90% of $RNR; prio 1 > | > |----1:3 - [ MAN ] rate=1Mbit; ceil=10Mbit-$RNR; prio 1 > | | (RMC=ceil) RMC = Root MAN Ceil > | | MAN destinations are marked with 0x1 Marker > | | > | |---1:30 - [ normal traffic ] > | | rate=500kbit;ceil=($RMC-$RNR-1)kbit; > | | prio 0; (u32 filter by ports AND fw mark) > | | > | \---1:31 - [ p2p traffic ] rate=1kbit; ceil=($RMC-$RNR-1)kbit; > | prio 1; (u32 filter by fw mark) > | > \----1:4 - [ LAN ] rate=89Mbit; ceil=89Mbit > > ________________________________________________________________________I assume that CS actually goes out to Internet and/or MAN, depending on the location of the server. I would make one CS class for each. Otherwise you may have 1MBit CS (which goes out to Internet) plus 1.5MBit Internet, which will work only if you got 2.5MBit Internet guaranteed in total. Likewise with MAN. Unless you really got that much bandwidth, this setup will not give you any good results at all. You could also use PRIO qdisc as a child to the HTB Internet / MAN classes to give CS absolute priority over HTTP over P2P. This approach worked very well for me and my flatmates, also for gaming. But that''s on a way slower line and without Internet/MAN distinction, so we''ve been happy with 200ms (versus 1000-5000ms when unshaped) pings. Regards Andreas Klauer
Jakub Wartak wrote:>You should use PRIO to divide traffic into 2 classes >1) ultra-critical ( here : cs game ) >2) other >3) very low prio > >( more info is on voip-info.org , section : QoS under Linux ) >you just have to mark CS packets and put them into the right PRIO class > > >Class 1:1 has prio 0 in htb and filters. other classes have a higher priority. I''ve made a test. I''ve added 1: ---- 1:1 --- 10: htb class sfq and bloked all other ports and traffic. With this setup I was unable to lower the ping to be less than 280. This made me come to the conclusion that ANY_ classification would introduce a packet delay. So if I use prio qdisc wouldn''t that be a classification? This is why I created the CS class as a root class. To answer to the other mail: CS maximum bandwidth consumption is about 500k. That is why the sum never exeeds the netrate. People in my LAN play almost exclusively in MAN, not in the Internet. I allocated such high bandwidth because htb would allocate the spare based on classes'' rates ratios. And since 1:1 is a root class as 1:2 and 1:3 (MAN and Internet respectively) it had to have such a rate even if it is not found in my real bandwidth.
On Thu, Mar 02, 2006 at 08:17:43PM +0200, Sorin Panca wrote:> I''ve made a test. I''ve added > 1: ---- 1:1 --- 10: > htb class sfqIf that SFQ is the standard sfq with a queuelength of 128 packets, it might be responsible for some of the delay. Unless you have connections in there that can choke the whole bandwidth (probably possible with CS if you set the rates up, I don''t know), you may not need SFQ for interactive bands at all.> People in my LAN play almost exclusively in MAN, not in the Internet. I > allocated such high bandwidth because htb would allocate the spare based > on classes'' rates ratios. And since 1:1 is a root class as 1:2 and 1:3 > (MAN and Internet respectively) it had to have such a rate even if it is > not found in my real bandwidth.I don''t think I follow your explanation here. How do you expect HTB to guarantee a rate for a class (that''s what it claims to do) when there is no bandwidth to back it up. I''ve never dealt with MANs before, so I may be completely wrong. Usually you should not have more than one root class, and you should not let HTB think it can use more bandwidth than there actually is. It''s extremely hard to understand the logic behind setups like this and therefore likely to get unexpected results from them. Regards Andreas Klauer
Andreas Klauer wrote:>If that SFQ is the standard sfq with a queuelength of 128 packets, >it might be responsible for some of the delay. >The command was: sfq perturb 10> Unless you have >connections in there that can choke the whole bandwidth (probably >possible with CS if you set the rates up, I don''t know), you may >not need SFQ for interactive bands at all. > > >I''ll be glad to use pfifo_fast but adding that qdisc explicitly I get a segmentation fault. If I don''t add a leaf qdisc, how can I be sure pfifo_fast is used? Or it''s just a pfifo?>>People in my LAN play almost exclusively in MAN, not in the Internet. I >>allocated such high bandwidth because htb would allocate the spare based >>on classes'' rates ratios. And since 1:1 is a root class as 1:2 and 1:3 >>(MAN and Internet respectively) it had to have such a rate even if it is >>not found in my real bandwidth. >> >>"//Any unused bandwidth can be used by any class which needs it (in proportion of its allocated share).">From luxik.cdi.cz/~devik/qos/htb/manual/userg.htm_In proportion of its allocated share._ //>I''ve never dealt with MANs before, so I may be completely wrong. >Usually you should not have more than one root class, and you should >not let HTB think it can use more bandwidth than there actually is. >It''s extremely hard to understand the logic behind setups like this >and therefore likely to get unexpected results from them. > >I am certain that CS does not have large banwidth requierments, but it needs very low latency. If I was to allocate a real bandwidth quantum, then the competition between CS and other traffic (MAN and Internet) would not be fair even if it has the lowest prio. So I had to lie htb about the available bandwidth based upon the fact that bandwidth requirements for CS are low and bursty. HTB would not allocate bandwidth to a service that doesn''t need it. (Or so I think; I may be wrong about that... Please correct me if I do.). I need more that one root class, because the bandwidths are separate and not supperposable. So what MAN can spare, Internet cannot use and vice-versa. (And MAN can spare a lot!) I tested a setup with a 1:A root class and 1:1; 1:2; 1:3 and 1:4 were child classes of 1:A. I got the same results. But I needed to lower the latency so I deleted that 1:A root class...
Hi list! I did this: 2: root qdisc prio 2:1 counter-strike 2:2 --> 1: htb qdisc for other traffic. 2:3 unused The shaping ocurrs both on the external and the internal interfaces. ping is in this case 500 - 1200 ms. without shapeing it is between 150 and 200 ms. :( Any ideas? Would ingress qdisc help or make things worse? _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Dnia piątek, 3 marca 2006 16:18, Sorin Panca napisał:> $tc qdisc add dev $DEV root handle 2: priofirst thing: use bands & priomap parameters ( bands=2 ; priomap = 16x "1" ) to direct all trafic defalult to the 2:2 class -- Jakub Wartak -vnull FreeBSD/OpenBSD/Linux/Solaris/Network Administrator vnull.pcnet.com.pl