[ 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:  Mon, 21 May 2007 19:01:55 -0400
David Burgess wrote:
> I think that would work. Or put another interface on your monowall, 
> just for
> the ftp server and put a pipe on that interface of 100k or so.
>
> On 5/19/07, Mark Ryan <markryan at cfl dot rr dot com> wrote:
>>
>> 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.
>>
>> Mark
>>
>
I have another interface free, didn't think about that.  That new pipe 
wouldn't borrow or allow borrowing, but it might be better than nothing.

nix4me