All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Brian J. Murrell" <brian@interlinx.bc.ca>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] HTB - prio and rate
Date: Fri, 02 Dec 2005 22:24:01 +0000	[thread overview]
Message-ID: <1133562243.20096.14.camel@pc.local> (raw)
In-Reply-To: <BF782D07436CAE4B931BFA5B2C68FF4F0F8E44@bmts1.ad.bmtseatech.co.uk>


[-- Attachment #1.1: Type: text/plain, Size: 1763 bytes --]

On Fri, 2005-12-02 at 21:48 +0100, Andreas Klauer wrote:
> 
> That's exactly what the PRIO qdisc does. In combination with HTB and SFQ, 
> it can be quite powerful, as low priority connections will completely 
> starve as long as there are higher priority packets to be sent.

Yeah, that is what I want, but why do I need HTB?  I notice also that
the LARTC Howto says:

        Because it doesn't actually shape, the same warning as for SFQ
        holds: either use it only if your physical link is really full
        or wrap it inside a classful qdisc that does shape. The latter
        holds for almost all cable modems and DSL devices.

I guess I am missing the reasoning for partitioning up the bandwidth
with HTB rather than just letting everyone/everything have an
opportunity to use the full bandwidth as long as something/somebody more
important is not using it.

> However, PRIO does no bandwidth limiting at all (has to be done by HTB or 
> similar), and does not provide connection-based fairness

Surely it will be connection based fairness within the priority class.
IOW, two ssh sessions could starve bittorrent but would each get about
50% of the available bandwidth.  I am fine with that.  I am also fine
with assigning priorities to users and their traffic within their user
priorities.

> (has to be done 
> by SFQ or similar), if you want to avoid one SSH session taking all the 
> bandwidth from the other.

Oh?  So one ssh could starve another?  Why?  Are the outbound SSH
packets not just put to the front of the queue in FIFO order?  I.e.
appended to the end of the "top of the queue" (the top band I guess it
is)?

b.

-- 
My other computer is your Microsoft Windows server.

Brian J. Murrell

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

  parent reply	other threads:[~2005-12-02 22:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-02 13:57 [LARTC] HTB - prio and rate Mark Lidstone
2005-12-02 20:25 ` Andreas Klauer
2005-12-02 20:31 ` Brian J. Murrell
2005-12-02 20:48 ` Andreas Klauer
2005-12-02 22:24 ` Brian J. Murrell [this message]
2005-12-03  6:04 ` Andreas Klauer
2005-12-03 23:14 ` Brian J. Murrell
2005-12-04  2:32 ` Jeffrey B. Ferland
2005-12-04  3:17 ` Jason Boxman
2005-12-04  3:26 ` Jason Boxman
2005-12-04  6:24 ` Andreas Klauer
2005-12-04 13:48 ` Brian J. Murrell
2005-12-04 15:14 ` Jeffrey B. Ferland
2005-12-04 16:05 ` Brian J. Murrell
2005-12-05  9:40 ` Mark Lidstone
2005-12-05 18:15 ` Andreas Klauer
2005-12-06 12:27 ` Mark Lidstone
2005-12-13  8:51 ` Mark Lidstone

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=1133562243.20096.14.camel@pc.local \
    --to=brian@interlinx.bc.ca \
    --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.