On 5/5/07, Mark Ryan <markryan at cfl dot rr dot com> wrote:
> David Burgess wrote:
> > On 5/3/07, Mark Ryan <markryan at cfl dot rr dot com> wrote:
> >> I run a ftp server from my home server on a cable modem. Currently i'm
> >> using a WRAP with monowall 1.23. I have traffic shaping working quite
> >> well however I still notice some lagginess when the ftp server is
> >> sending at max speed. I notice the lag on web surfing. Basically i
> >> have the ftp traffic tagged as hated traffic, dns and small packets ate
> >> prio 1 and ack as prio 3, and everything else as bulk.
> >> So it seems that web surfing is still being affected somewhat, but not
> >> whole lot.
> >> I have the pipe limit set to 110KB for the upload on my 10mbit / 1mbit
> >> cable connection. So its sufficiently lower than the max.
> >> My question is, is there a way to improver the browser response?
> >> Perhaps is there a way to have 2 pipes? With the ftp on 1 pipe and
> >> everything else on the other pipe? With the everything else pipe
> >> strict priority over the ftp?
> >> I dont care if the ftp slows down, i want maximum responsiveness for
> >> surfing.
> >> Thanks,
> >> Mark
> > You're using the magic shaper wizard as a starting point by the sounds
> > it. I'll make the assumption that you're using a single pipe for your
> > upload
> > traffic.
> > By queuing all your traffic through a single pipe, as the wizard does,
> > any
> > queue can "borrow" bandwidth from any other queue. In other words, your
> > lowest-priority ftp packets can fill the whole pipe if there is
> > nothing else
> > being uploaded through the router in question. As soon as a
> > higher-priority
> > packet enters the pipe, it will be 'bumped' up in line, but it still
> > has to
> > wait for whatever packet is in the process of being sent at that
> > and ftp and p2p packets can be quite large, hence the lag you observed
> > surfing (the ack packets have to wait for these bigger ftp packets to
> > clear
> > the pipe).
> > If you decide to make 2 upload pipes, say 80KB for the first pipe, and
> > send
> > only ftp through it, then your ftp uploads will never exceed that
> > value and
> > your ack packets (for web surfing, etc) should enjoy much better
> > responsiveness, as they have 35KB of reserved bandwidth just waiting for
> > them.
> > Size your 2 pipes judiciously according to your needs. If you habitually
> > upload large files such as email attachments, web content, or scp
> > transfers,
> > then you should consider queuing these into the 'bulk' pipe along with
> > the
> > ftp traffic. If you're into gaming, which requires
> > low-latency/high-bandwidth upstream, then you'll want to keep your
> > non-bulk
> > pipe fairly big at the cost of slower bulk traffic all the time.
> > On the other hand, if you're mostly just surfing and sending the odd
> > email,
> > then go ahead and give your bulk pipe a bigger share. You may need
> > more than
> > a few KB/s of upload bandwidth for this type of usage.
> > Good luck.
> > db
> On linux I used Hierarchial Token Bucket traffic shaping and it worked a
> little different. I could setup multiple pipes within a pipe and assign
> max bw and borrowing characteristics to those. It worked very well. My
> FTp would be limited to 100K but the other pipe was set at 125K. FTP
> would wold go 100 and yet i still had 25K to play with. The pipes
> borrowed from each other too.
> Am I missing something with the m0n0wall traffic shaper? Is a setup
> such as this possible? It doesnt appear to be.
> Basicaly, i would want my overall connection capped at 125K. Then I
> would want 2 pipes assigned to that. The first being a fullsheep 125K
> pipe for web, ack, ping, email, small packet, etc. The second would be
> a pipe set to 100K for ftp traffic. Then i would need a way to have
> pipe 1 borrow from pipe 2 when it needed it.
Yeah, I run linux at home and mono at work and I must admit that while I
love mono (and have considered running it at home), I have yet to find
another traffic shaper that gives me the fine control that linux does.
So with HTB your root qdisc is essentially equivalent to mono's pipe. Or if
you have more than one egress pipe in mono then you could compare that to
having sibling classes in HTB, with an implicit parent qdisc of the combined
value of your pipes.
You know that sibling classes in HTB can borrow from each other up to the
max that you set. In mono your queues don't have a max except for the
containing pipe, and thus they can always borrow from other queues until
they fill their pipe.
By setting your ftp's max in linux (100K) to less than your root qdisc max
(125K) you were effectively preventing a large ftp packet from jamming your
root qdisc. As far as I know in mono, there is no way to accomplish this
other than to put ftp in a separate pipe from your ack packets, and thus
they can never borrow from each other.
Like I said, mono is great, but unless I've grossly misunderstood this whole
sport, linux is still the traffic-shaping king in my books. Apparently pf
and altq approach linux in this functionality, but I still like being able
to use a combination of prio and htb, something that pf doesn't appear to