All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] counter-strike
@ 2006-03-02 11:45 Sorin Panca
  2006-03-02 14:23 ` Jakub Wartak
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: Sorin Panca @ 2006-03-02 11:45 UTC (permalink / raw)
  To: lartc

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ê% of $RNR; ceil=$RNR;
    |     |                             prio 0; (u32 filter by ports)
    |     |
    |     \---1:21 - [ p2p traffic ] (default class) rate=1kbit;
    |                                ceilê% of $RNR; prio 1
    |
    |----1:3       - [ MAN ] rate=1Mbit; ceil\x10Mbit-$RNR; prio 1
    |     |                  (RMCŒil) RMC = Root MAN Ceil
    |     |                  MAN destinations are marked with 0x1 Marker
    |     |
    |     |---1:30 - [ normal traffic ]
    |     |                    rateP0kbit;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âMbit; ceilâMbit

________________________________________________________________________


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

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LARTC] counter-strike
  2006-03-02 11:45 [LARTC] counter-strike Sorin Panca
@ 2006-03-02 14:23 ` Jakub Wartak
  2006-03-02 15:07 ` Andreas Klauer
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Jakub Wartak @ 2006-03-02 14:23 UTC (permalink / raw)
  To: lartc

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 www.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
http://vnull.pcnet.com.pl/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LARTC] counter-strike
  2006-03-02 11:45 [LARTC] counter-strike Sorin Panca
  2006-03-02 14:23 ` Jakub Wartak
@ 2006-03-02 15:07 ` Andreas Klauer
  2006-03-02 18:17 ` Sorin Panca
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Andreas Klauer @ 2006-03-02 15:07 UTC (permalink / raw)
  To: lartc

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1252", Size: 2411 bytes --]

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% of $RNR; ceil=$RNR;
>     |     |                             prio 0; (u32 filter by ports)
>     |     |
>     |     \---1:21 - [ p2p traffic ] (default class) rate=1kbit;
>     |                                ceil% of $RNR; prio 1
>     |
>     |----1:3       - [ MAN ] rate=1Mbit; ceil\x10Mbit-$RNR; prio 1
>     |     |                  (RMCÎil) RMC = Root MAN Ceil
>     |     |                  MAN destinations are marked with 0x1 Marker
>     |     |
>     |     |---1:30 - [ normal traffic ]
>     |     |                    rateP0kbit;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‰Mbit; ceil‰Mbit
> 
> ________________________________________________________________________

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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LARTC] counter-strike
  2006-03-02 11:45 [LARTC] counter-strike Sorin Panca
  2006-03-02 14:23 ` Jakub Wartak
  2006-03-02 15:07 ` Andreas Klauer
@ 2006-03-02 18:17 ` Sorin Panca
  2006-03-02 18:53 ` Andreas Klauer
  2006-03-02 20:13 ` Sorin Panca
  4 siblings, 0 replies; 6+ messages in thread
From: Sorin Panca @ 2006-03-02 18:17 UTC (permalink / raw)
  To: lartc

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 www.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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LARTC] counter-strike
  2006-03-02 11:45 [LARTC] counter-strike Sorin Panca
                   ` (2 preceding siblings ...)
  2006-03-02 18:17 ` Sorin Panca
@ 2006-03-02 18:53 ` Andreas Klauer
  2006-03-02 20:13 ` Sorin Panca
  4 siblings, 0 replies; 6+ messages in thread
From: Andreas Klauer @ 2006-03-02 18:53 UTC (permalink / raw)
  To: lartc

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     sfq

If 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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [LARTC] counter-strike
  2006-03-02 11:45 [LARTC] counter-strike Sorin Panca
                   ` (3 preceding siblings ...)
  2006-03-02 18:53 ` Andreas Klauer
@ 2006-03-02 20:13 ` Sorin Panca
  4 siblings, 0 replies; 6+ messages in thread
From: Sorin Panca @ 2006-03-02 20:13 UTC (permalink / raw)
  To: lartc

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 http://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...
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2006-03-02 20:13 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-02 11:45 [LARTC] counter-strike Sorin Panca
2006-03-02 14:23 ` Jakub Wartak
2006-03-02 15:07 ` Andreas Klauer
2006-03-02 18:17 ` Sorin Panca
2006-03-02 18:53 ` Andreas Klauer
2006-03-02 20:13 ` Sorin Panca

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.