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
>