From: Sorin Panca <sorin.panca@gmail.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] counter-strike
Date: Thu, 02 Mar 2006 20:13:29 +0000 [thread overview]
Message-ID: <440751E9.5030805@gmail.com> (raw)
In-Reply-To: <4406DABD.8050700@gmail.com>
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
prev parent reply other threads:[~2006-03-02 20:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=440751E9.5030805@gmail.com \
--to=sorin.panca@gmail.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox