|
||||||||||
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 agree. You hit the nail on the head and you obviously understand exactly what my problem is. Linux solves this perfectly. I ran ipcop for years with a perfect traffic shaper, but I decided to buy a WRAP and ipcop doesnt run well on it. They have a WRAP version called embcop but it is not very optimized for the hardware. Monowall is great, but the traffic shaper just isn't up to snuff. I guess i'm stuck with poor performance unless I get rid of the WRAP on go back to a pc for the router. It would be sweet if the freebsd folks could get a HTB-like traffic shaper going. Mark |