David Burgess wrote:
> 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
>> >> 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
>> >> whole lot.
>> >> I have the pipe limit set to 110KB for the upload on my 10mbit /
>> >> 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,
>> > 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
>> > 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
> 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
> (125K) you were effectively preventing a large ftp packet from jamming
> 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
> 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
> to use a combination of prio and htb, something that pf doesn't appear to
I've been thinking about this some more. The only way I believe that
it's possible to get better performance is to run a traffic shaper on
the lan server to limit the ftp traffic to a bit slower than the
monowall pipe is set to. This would free up just a bit of overhead speed.