Having just switched ISP's I now have a (theoretical) 2 gig connection. My existing Hex S, with it's 1G ethernet ports, obviously can't handle this.

Would the RB5009UG+S+in be an appropriate upgrade here? I do have firewall rules that need to be used - this will be a router/firewall, not just a switch.

Can't go wrong with RB5009. It's more than capable of 2Gig routing.

Playing with my shiny new RB5009 - it will indeed pass the full 2G (actually, 2.2G) I'm getting from the cable provider. That with fasttrack enabled.

However, the instant I enable a queue of any kind the speedtest drops to 1.2G maximum. While I probably don't need any QoS - I was hoping to optimize, and learn, my new link.

Am I missing something - or is a 2G link beyond the CPU capabilities of the RB5009 without fasttrack? In which case - I'm probably not willing to spend what would be required.

Correct, the Rb5009 is capable of handling up roughly 3gigs. Surprizing it loses so much steam by turning fast track off.
Its fair to say that MT should include another line entry in their results pages
25 filters (fasttrack off)

Check your CPU usage (not avg usage you get at the top of the winbox but per core usage in System/Resources/CPU).

If you are hitting something like 85-100% on any core you got your answer.

CPU doesn't get above 50% - maybe not even 40% - but the speed is cut in half regardless.

Even with fasttrack not working (I currently don't have fasttrack active), it can handle 2.2+Gbps Download (my ISP limit due to GPON) with the default firewall rules (plus 10+ additional filter and dst-nat rules), but no queues or mangle rules. That includes IPv6 (which could never use fasttrack), in a full VLAN configuration. My Upload is limited by ISP and doesn't go above 1Gbps so I can't test the upload limit.

It's probably due to the extra processing required for queues. I've read that CAKE is very CPU-intensive?

Serious, even the CR2004 cannot do 2gigs with fastrack disabled.
Okay, I just sent a suggestion to MT, to add 25 filter rules fastrack-off LINE to results so people can match up expectations and purchase an appropriate router.

It's probably due to the extra processing required for queues. I've read that CAKE is very CPU-intensive?

Yeah the queue type might affect things. I'd think fq-codel might be better starting choice.

Is the queue dropping anything that might cause less bandwidth?

Are you using a queue tree or simple queue?

I have no idea if that improve speed, but if there is CPU to spare other queue choices might be more efficient.

Slight revision.

My current link is 2G down/100M up via cable/DOCSIS. I can run a queue tree on the upload without problems. It's only when I try to run on the download/bridge interface that my 2G gets throttled down to 1.2G.

Since the real limiting factor, for my use case, will be upload sharing I should be fine with this. I don't know how much processing power is needed to actually handle a 2.5G connection but obviously the RB5009 isn't up to it - though obviously it's good enough for 1G.

A download (incoming) queue isn't as not as useful IMO. I'd keep the upload (outbound) queues.

I presume you're using TCP-based speediest, what happens when your run a speedtest/btest/iperf for 60 seconds. I do suspect you'd see higher speeds even with a download queue when a longer test than something like ookla. Or try UDP speedtest with iperf or something.