All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Boxman <jasonb@edseek.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] SEPARATING VOIP AND SURFING
Date: Tue, 16 Nov 2004 01:33:04 +0000	[thread overview]
Message-ID: <200411152033.04900.jasonb@edseek.com> (raw)
In-Reply-To: <20041109175203.11372.qmail@web41524.mail.yahoo.com>

On Monday 15 November 2004 20:06, Ricardo Soria wrote:
<snip>
> Dear Andy:
>
> Very thanks for your answer.  However, I need a little
> bit more extended explanation.
>
> First, you say that I should "back off more from link
> speed - total ceils to about 80% and share that
> between interactive and bulk".  So, do you mean that
> if I have a total 512Kbit link, and 2 child classes, I
> should not divide the whole 512kbit between the 2
> classes, but, I should only divide 410kbit between
> them, and share the remaining 102kbit between them??
> Or do you mean I should only consider 410kbit as the
> whole link capacity??

I think he meant to treat your link as if it were only 410kbit.  With some 
testing you can verify just how close to 100% of your advertised capacity you 
can get, but 80% is often a good place to start.

> Second, you say that I should not use SFQ as a
> sub-qdisc, because of the lenght of the queue, being
> it ESFQ (new for me) a better choice.  But later, you
> say I should use SFQ for bulk traffic (I think you
> refer surfing as "bulk", and voip as "interactive").
> So, should I use SFQ for bulk classes and ESFQ for
> interactive classes ??  Or, should I use ESFQ for all
> leaf classes??  Or, should I use ESFQ for bulk classes
> and default (pfifo, I think) for interactive classes??

I am curious about this myself.  I placed a default sfq qdisc with the 128 
queue default on a p2p class that had a rate of 144kbit and it routinely 
spiked to about 150kbit several times a second.  If I use pfifo with a queue 
length of 10 I find my utilization for that class at around 146kbit instead.  
Is it the queue length causing this behavior?

-- 

Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2004-11-16  1:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-09 17:52 [LARTC] SEPARATING VOIP AND SURFING Ricardo Soria
2004-11-15 12:42 ` Andy Furniss
2004-11-16  1:06 ` Ricardo Soria
2004-11-16  1:33 ` Jason Boxman [this message]
2004-11-16 14:53 ` Andy Furniss
2004-11-16 17:08 ` Jason Boxman
2004-11-17  1:15 ` Andy Furniss
2004-11-17 22:36 ` Ricardo Soria
2004-11-18  0:44 ` Andy Furniss
2004-11-18  1:08 ` Rick Marshall
2004-11-23 15:57 ` Ricardo Soria
2004-11-24 19:08 ` Ricardo Soria
2004-11-24 22:19 ` Ricardo Soria
2004-11-24 22:42 ` Rick Marshall
2004-11-25 10:48 ` Andy Furniss
2004-11-25 15:55 ` Andy Furniss
2004-11-28 23:50 ` Ricardo Soria
2004-11-29 21:53 ` Andy Furniss
2004-11-30  2:07 ` Ricardo Soria
2004-11-30  2:39 ` Andy Furniss
2004-11-30 12:23 ` Andy Furniss
2004-12-01 15:16 ` Ricardo Soria
2004-12-01 21:57 ` Andy Furniss
2004-12-06 22:54 ` Ricardo Soria

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=200411152033.04900.jasonb@edseek.com \
    --to=jasonb@edseek.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.