Thanks so much, Adam. I been thinking about how to accomplish this all day. Just wasnt sure how to code it, and your suggestion is basically identical to what I was envisioning.
On Mon, Oct 13, 2014 at 4:16 PM, Adam Moffett via Af <[email protected]> wrote: > > Since it's on the forefront of my mind now, I just went ahead and added a > "tiny-download" packet mark for connections that moved less than 1 million > bytes. tiny-download gets priority 6 in the queue tree. Something like > 20% of traffic seems to fit that description. > > I think I'll keep it. > > >> Have you tried PCQ with lower priority on connections that have moved >> more data? See below. That's saying any connection that has moved less >> than 50,000,000 bytes gets priority 7, while any connection moving more >> than that gets the default priority 8. >> >> Before I did this, if I ran a torrent at my house I would get a crummy >> speed test and people in the house would complain about web pages being >> slow. After doing this, the first thing I did was start up a torrent and >> let it run for awhile, then do a speed test. You could see the throughput >> in uTorrent drop while the speedtest went full throttle. So email and >> light web browsing (and speed tests) can hum along while a torrent or video >> stream is hosing the connection. I'm running this at the router at the >> tower by the way. >> >> It's something like this: >> /ip firewall mangle >> add action=mark-connection chain=prerouting new-connection-mark=\ >> tcp-connection protocol=tcp >> add action=mark-packet chain=prerouting comment=short connection-bytes=\ >> 0-50000000 connection-mark=tcp-connection >> new-packet-mark=short-download \ >> passthrough=no protocol=tcp >> add action=mark-packet chain=prerouting comment=long connection-mark=\ >> tcp-connection new-packet-mark=long-download passthrough=no >> protocol=tcp >> add action=mark-packet chain=prerouting comment="short udp" >> connection-bytes=\ >> 0-50000000 new-packet-mark=short-download passthrough=no protocol=udp >> add action=mark-packet chain=prerouting comment="long udp" >> new-packet-mark=\ >> long-download passthrough=no protocol=udp >> >> /queue type >> add kind=pcq name="PCQ short Download" pcq-classifier=src-address,dst-address >> \ >> pcq-dst-address6-mask=64 pcq-limit=5k pcq-src-address6-mask=64 \ >> pcq-total-limit=40000 >> add kind=pcq name="PCQ long download" pcq-classifier=src-address,dst-address >> \ >> pcq-dst-address6-mask=64 pcq-src-address6-mask=64 >> pcq-total-limit=40000 >> >> /queue tree >> add name=queue1 parent=global queue=default >> add name=queue8 packet-mark=short-download parent=queue1 priority=7 >> queue="PCQ short Download" >> add name=queue9 packet-mark=long-download parent=queue1 queue="PCQ long >> download" >> >> I believe in the definition of the PCQ queue type you could also limit >> the speed of each connection. >> A Torrent client could still hose this.....I'm not normally trying to get >> more than one torrent at a time, so for my house it works great, but if you >> have lots of torrents running and they each open many connections, it could >> take quite awhile before the individual connections move enough data to hit >> 50meg. >> >> I was thinking I would alter it with 3 or four stages of connection >> length with gradually decreasing priority levels. I just haven't gotten >> around to it. >> >> So it's becoming a reoccurring nightmare for me. I get a customer >>> calling in saying their internet is slow. It ends up being their upstream >>> or downstream or both are totally maxed out for hours on end. >>> Unfortunately, my responsibility does not stop there. >>> >>> We have been going the route of installing Mikrotik's in the customer >>> home, which helps us identify the problem. But what do we do from there? >>> >>> I feel like the overall bandwidth isnt the ENTIRE problem. With more >>> intelligent usage, more people can use it simultaneously. Of course, giving >>> them more speed would help, but I feel like it's a bandaid around the big >>> picture, which is the fact that nothing plays nice with anything else. >>> >>> Are there any mikrotik guru's here that could figure something out that >>> we could preload on all these mikrotik routers that would help minimize >>> this issue? >>> >>> In my mind, I feel like the solution lies in the prioritization of each >>> connection, without putting a hard limit on any one device. I just can't >>> seem to figure out the proper implementation. >>> >>> Are any of you seeing this reoccurring nightmare? >>> >>> >> >
