This is exactly what I had envisioned in my mind. I can not thank you enough. On Oct 13, 2014 3:33 PM, "Adam Moffett via Af" <af@afmug.com> wrote:
> > 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? >> >> >
