All of lore.kernel.org
 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 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.