New to all this. I figured I’d ask before random experimenting.
Last night I finally got a PCQ queue figured out, and it appeared to be doing its job. If I d/l something on client 1 and then on client 2, they both get 50% of available bandwidth. When one finishes, the other gets 100%. Beautiful.
This morning I noticed my surfing was sluggish and d/l was shyte. Nothing else was downloading, but I noticed the upload was saturated with a CrashPlan backup. Upload was effectively shared when I did a test, but d/l was crap.
So I think what’s happening is the u/l is being completely saturated, which is not allowing acknowledgement packets to get through effeciently and that’s killing d/l. And I think the solution is going to be giving ACK (anything else?) priority. Am I close? Does that play nice with the PCQ that’s already setup?
One thing I am confused on is why there’s a max-limit setting for the PCQ if that doesn’t restrict the u/l and prevent saturation??
Thank you for your time. My config below:
/ip firewall filter
add chain=input comment="defconf: accept ICMP" protocol=icmp
add chain=input comment="defconf: accept established,related" connection-state=\
established,related
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=\
01-WAN
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related disabled=yes
add chain=forward comment="defconf: accept established,related" \
connection-state=established,related
add action=drop chain=forward comment="defconf: drop invalid" connection-state=\
invalid
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface=01-WAN
/ip firewall mangle
add action=mark-connection chain=forward dst-address=192.168.1.0/24 \
new-connection-mark=conmarkdownload src-address=!192.168.1.0/24
add action=mark-connection chain=forward dst-address=!192.168.1.0/24 \
new-connection-mark=conmarkupload src-address=192.168.1.0/24
add action=jump chain=forward connection-mark=!no-mark jump-target=pktmark
add action=mark-packet chain=pktmark connection-mark=conmarkdownload \
new-packet-mark=packmarkdownload
add action=mark-packet chain=pktmark connection-mark=conmarkupload \
new-packet-mark=packmarkupload
/queue type
add kind=pcq name=pcq-downloads pcq-classifier=dst-address pcq-limit=100KiB pcq-total-limit=500KiB
add kind=pcq name=pcq-uploads pcq-classifier=src-address pcq-limit=20KiB pcq-total-limit=100KiB
/queue tree
add max-limit=15200k name=qosdownload parent=global queue=default
add max-limit=850k name=qosupload parent=global queue=default
add limit-at=170k max-limit=850k name=limitupload packet-mark=packmarkupload parent=qosupload queue=pcq-uploads
add limit-at=3040k max-limit=15200k name=limitdownload packet-mark=packmarkdownload parent=qosdownload queue=\
pcq-downloads
Didn’t read the config yet but your thinking about ACK being lost in congestion is sound. PCQ max-limit upstream should be just a touch lower than your actual upstream speed. If it’s too high then it won’t start limiting/sharing properly, and thus the policing on the ISP circuit will start dropping stuff, and that’s almost always going to be “first come, first dropped” with no regard to QoS or fairness.
If your PCQ is properly configured to share upstream bandwidth per-src-IP THEN hosts should be safe from each-other’s streams, but you could starve your OWN share of the bandwidth if surfing from the machine that’s actually doing the uploading…
You could put a higher-priority queue ahead of the PCQ, and have it match only top/ack packets. I’d suggest instead of prioritizing it, give it a minimum bandwidth guarantee (limit-at) of something like 50% of the total upstream.
I set it to 85%. When I saw the problem, I dropped it lower, and lower… problem never went away (everything just got slower). That’s when I started to wonder of that leftover 15% wasn’t being used the way I expected. From your post, I think it is… so now I’m confused why I had a problem at all. Just in case it was a temporary ISP issue, I disabled the interface for the “offending” computer (the one doing the backup) and tried a speed test on my PC and sure enough everything was normal. Re-enable the interface, and my d/l was sapped again.
I wonder if I have something screwed up on the u/l rules.
Possibly. You could also try a mangle rule to mark upstream ACK packets and adding a queue for them with limit-at set to something like 40% and max-limit set to 50% and see if that helps.
I just read your mangle rules and they look wrong. You’re con marking for upload or download. Any given connection is both up and download directions. You need one mark for all connections and use different packet marks based on out-interface.
there are some info here and also some suggestions from me…
http://forum.mikrotik.com/t/strange-pcq-issue/97029/1
Thanks, that makes sense. I just copied those from this thread. Nobody challenged his so I figured he knew what he was doing 
Come to think of it, you shouldn’t need mangling/marking for a simple global simple queue with the target set to be the LAN IP range…
It knows upstream/downstream automatically.
Oh. Do you think you could give me a sample script so I can see what you mean?
Just add a simple queue with no parent and no packet marks to check for. Set target to be your LAN range e.g. 192.168.88.0/24. Set the max-limit to the appropriate up and down amounts, and queue type up = PCQ-up / down = PCQ-down
If you just want fair sharing, put no per-queue rates in the configs of your PCQ type configurations. Just set down to match to-ip and up to match from-ip
In general, you only need to use packet marks if you’re doing QoS/priority stuff or using queue trees.
Upon reflection, you may need to use to-address on the up PCQ as well because HTB / queues happens after src NAT. Or maybe set the queue parent to be the LAN bridge / interface
The pcq-upload-default queue type has Src. Address checked. You’re saying to change it to Dst. Address? Or have both checked?
This doesn’t appear to be possible. I can’t arbitrarily enter anything into Parent, and the dropdown list contains no interfaces, only “none” and the name of the queue I’m working on (which seems weird to have something capable of being its own parent.)
I just tried it all three ways (src, dst, both) and in all cases… when PC 1 is saturating upload, PC 2 can’t do squat. I have upload of around 1M. So I set max-Limit to 850K. I tried 750, 512, 256… doesn’t matter, it always saturates. What am I missing?
set pcq-upload rate to something less than max upload limit.
so if max upload limit is 1M set 800k so one ip uploading does not saturate connection
another one u can try, dont use queue pcq-upload for upload. use “synchronous-default” or “default”
Are you talking about the “rate” field in the Queue Type dialog? I thought that had to be zero to share available equally. If I do as you suggest… that keeps ONE user from hogging upload… but what happens if a 2nd is also uploading? Aren’t they both then trying to take 80% in that scenario?
I’m not sure why there is saturation though. Let’s say my “true” upload is 1M. I set max-limit to 850K. PCQ attempts to share that among users during congestion, right? So if one is hammering upload, it is going to take the whole 850K… but that still leaves 150K really available. PC #2 comes online and tries to download, which of course requires some upload for acknowledgement packets. The whole point of the PCQ is to guarantee PC#2 gets up to half (425k)… surely those ACKs don’t take even close to that, so what’s going on?
yes that field.
i have the same problem with my asynchronous adsl 10M/1M when my iphone is fully uploading backup every day.
i found those sollutions that help my situation. please test and reply here