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?
