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 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.