All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Boxman <jasonb@edseek.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Re: Shaping incoming traffic on the other interface
Date: Thu, 10 Jun 2004 20:30:52 +0000	[thread overview]
Message-ID: <200406101630.52938.jasonb@edseek.com> (raw)
In-Reply-To: <87u0xjtma8.fsf@stark.xeocode.com>

On Thursday 10 June 2004 16:07, Greg Stark wrote:
<snip>
> I'm using sfq as well. But I'm wondering if I wouldn't be better off with
> pfifo with a short queue. One of the entries in the HTB faq suggests using
> sfq can make it hard to limit bandwidth precisely because it requires
> enough memory that tcp_wmem kicks in. Or is that only for locally generated
> traffic?

I tried sticking a limit 10 pfifo on my PRIO n:1 to no avail.  ICMP which I 
add to that class wasn't any better off.  The only sure thing I found was to 
continually reduce my rate.  I find for best performance I'm stuck with 62.5% 
of my 256Kbps upstream.  (We really need some kind of realtime PPPoATM 
scheduler.)  I can run at 75%, but the lag is noticeable when browsing the 
Web, for example.

As for SFQ, you can use ESFQ which lets you specify the actual queue limit I 
believe, or you can recompile SFQ and redefine[1] the queue length in the 
source code.

[1] http://www.docum.org/stef.coene/qos/faq/cache/21.html

<snip>
> I'm still unsure whether I want to be using iptables to mark packets or
> stick with the tc filters I inherited from wshaper.

I'd suggest going with IPTables/Netfilter.  You can't really go wrong.  If 
you're running a firewall with IPTables already, then you're good to go.  
Plus, you cannot deal with most p2p traffic using straight `tc` filters.  As 
always, I suggest IPP2P and L7-Filter for 2.4 and 2.6 respectively.  L7 seems 
to catch 99 - 100% of my 'edonkey' traffic.

> Marking packets in iptables has the advantage that it knows which packets
> were natted and what the host on the far side of the NAT is. It also has
> some more flexible methods for matching.
>
> One thing I'm wondering, is it possible in iptables to mark all packets
> after some amount of traffic? Like, for example I want port 80 traffic to
> be higher priority than ftp-data and bittorrent, but only for regular
> browsing. If I download something over, say, 200k I want to to get
> downgraded to the same group as ftp-data and bittorrent. Also, bittorrent
> has a habit of occasionally using random ports and doesn't set TOS. So if
> iptables knew that that flow had already transfered more than some
> threshold of data it could downgrade it.

Yes, you can do that.  I have been meaning to do it for my HTTP traffic but I 
keep forgetting.  You might try something like this[2].  Or maybe this[3].

[2] http://www.docum.org/stef.coene/qos/faq/cache/49.html
[3] http://www.netfilter.org/patch-o-matic/pom-extra.html#pom-extra-connbytes

> Actually another possibility is any flow open for more than, say, 30s could
> be downgraded.

I just read a paper somewhere that mentioned research into that approach.  
Wish I could remember where I found it now.  It was suggested that giving 
short flows a higher priority over longer lived flows would result in better 
performance for both.

> I don't think the qdiscs handle things at this granularity, but iptables
> sure does. I don't recall seeing any of these features but it doesn't seem
> like it would be much of a stretch for it.

You might check out some of the other patch-o-matic extensions at the above 
URL.

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

  parent reply	other threads:[~2004-06-10 20:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-10 16:23 [LARTC] Re: Shaping incoming traffic on the other interface Greg Stark
2004-06-10 16:54 ` Matteo Brusa
2004-06-10 20:07 ` Greg Stark
2004-06-10 20:30 ` Jason Boxman [this message]
2004-06-10 20:33 ` Andreas Klauer
2004-06-11  5:13 ` Greg Stark

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