[ previous ] [ next ] [ threads ]
 From:  Mark Ryan <markryan at cfl dot rr dot com>
 To:  David Burgess <apt dot get at gmail dot com>
 Cc:  Monowall Support List <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] traffic shaper help
 Date:  Sat, 19 May 2007 19:24:10 -0400
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 
>> 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
>> a
>> >> 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
>> having
>> >> strict priority over the ftp?
>> >>
>> >> I dont care if the ftp slows down, i want maximum responsiveness for
>> web
>> >> surfing.
>> >>
>> >> Thanks,
>> >> Mark
>> >
>> >
>> > You're using the magic shaper wizard as a starting point by the sounds
>> of
>> > 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
>> instant,
>> > and ftp and p2p packets can be quite large, hence the lag you observed
>> in
>> > 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
>> >
>> Exactly!
>> 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.
>> Mark
> 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
> offer.
> db
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.