From: Peter Surda <shurdeek@routehat.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] wrr question
Date: Wed, 08 Jun 2005 20:23:21 +0000 [thread overview]
Message-ID: <20055822232116425@mail.routehat.org> (raw)
In-Reply-To: <fad9d48405060712357e1655aa@mail.gmail.com>
On Wed, 8 Jun 2005 22:01:42 +0200 Kenneth Kalmer <kenneth.kalmer@gmail.com>
wrote:
>Hmm, just has an idea, dunno if this will work...
>
>Can I use WRR on an IMQ disc
Yes, this works without problems (Route Hat's tc script does it).
>to make sure that the incoming traffic is
>not saturated by a single squid request? Squid runs transparently, and
>I've noticed that it downloads the file faster than the client gets it
>from squid, so big downloads can very easily congest the link...
This indicates an incorrect setup. Limiting squid's connections to clients won't
have the expected effect, the connections are handled asynchronously.
>Possible?
Now, combining WRR and Squid is another topic. It is possible, but difficult.
On the WRR website, there is a program called "proxyremap" that should solve
this in userspace. I never tried it, but it is supposed to work.
The other option is to use squid with tproxy patch. This requires a
rearrangement of the network setup though (tproxy and NAT don't work on the same
machine, and because tproxy mangles IP but not MAC, you have to put it on a
separate segment or use it as a next hop or a bridge, or use other tricks, such
as arptables' MAC mangling).
I only tried the last one (tproxy + mac mangling), for about 10 days, on a
network with about 60 local computers, and it was a horrible hack, but worked.
The reason that I only used it for such a short time wasn't that there were
problems, I just wanted to test it with Route Hat in case some customers request
it.
Unfortunately, TPROXY mailing list mentions a couple of times that rewriting
TPROXY so that it works with NAT isn't easy, so for foreseeable future we're
stuck with the above "solutions" (well, most of them are workarounds).
Other than that, you can play with squid's delay pools. Unless however you
fine-tune the proxies priority (in my experience very difficult) you're still
screwed.
Yours sincerely,
Peter
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next prev parent reply other threads:[~2005-06-08 20:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-07 19:35 [LARTC] wrr question Kenneth Kalmer
2005-06-07 19:41 ` Peter Surda
2005-06-07 21:24 ` Jonathan Day
2005-06-07 21:33 ` Kenneth Kalmer
2005-06-07 21:46 ` Peter Surda
2005-06-08 20:01 ` Kenneth Kalmer
2005-06-08 20:23 ` Peter Surda [this message]
2005-06-09 11:15 ` Kenneth Kalmer
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=20055822232116425@mail.routehat.org \
--to=shurdeek@routehat.org \
--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.