Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: gypsy <gypsy@iswest.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Download and upload independency
Date: Thu, 19 Jan 2006 16:07:47 +0000	[thread overview]
Message-ID: <43CFB953.8EFE6025@iswest.com> (raw)
In-Reply-To: <43CE0C95.4050409@e-attico.net>

Diego Cabrero wrote:
> 
> Hello everyone:
> As it is known, when you limit uplink bandwidth it usually gets downlink
> bandwidth to a lower value.
> I just want to know what is the optimal configuration for eth1 and imq0
> according to some variables of  tc(HTB), txqueuelen, mtu, etc. to make
> these packet flows less independent on an ethernet based network.
> 
> Thank you in advance.
> 
> -Diego

Diego,

Since nobody else answered this, I'll give it a try.

I accelerate all small packets on the egress side because this sends the
ACK packets ASAP.  Doing this improves download speed.

I use 'quantum 1514', 'prio #' and 'burst #k' in my 'tc class add'
lines.  E.G.:
tc class add dev eth1 parent 1:1 classid 1:20 htb rate $RATE ceil \
  $CEIL burst 16k quantum 1514 prio 2

Make sure the sum of the rates is <= the parent rate.  Some say it is
better to patch htb to deque one packet at a time rather than 2.  I
don't.

Be sure you change your linux kernel source
  vi ~linux/include/net/pkt_sched.h
so it uses PSCHED_CPU because JIFFIES just does not cut the mustard.

I am just now implementing IMQ.  What a pain getting it to compile (bad
linux 2.4 patch)!  I can't say yet if this is the right approach, but I
intend to accelerate SSH and put everything else into a default bulk
class, adding an esfq qdisc:
~'parent 1:20 handle 20: esfq limit 64 depth 64 divisor 10 \
    hash dst perturb 20'
and then filter SSH by source and dest port 22 into accelerated 1:10.  I
want to shape the incoming flows by where the packets come from - but I
might change my mind after I try this :o

I looked at documentation on the DSL sites about tweaking, then at Oskar
Andreasson's tutorial to understand the /proc settings, but I can't find
my notes about what I changed.  I did increase buffer sizes, but I can't
recall anything further right now...  IIRC, most things were correct so
I did not change much.
--
gypsy
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

  reply	other threads:[~2006-01-19 16:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-18  9:38 [LARTC] Download and upload independency Diego Cabrero
2006-01-19 16:07 ` gypsy [this message]
2006-01-20 13:20 ` Diego Cabrero
2006-01-21  5:15 ` gypsy

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=43CFB953.8EFE6025@iswest.com \
    --to=gypsy@iswest.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