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:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
