Ok, this might seem like a bit of a niche product but I think I can bring many around to seeing this as a very useful, and usable on TONS of links.

RouterOSv7 exclusive (needs fq_codel)

4 pair PoE in/out for pass through.
Something like a 'metal' and a GPeR IP67.
wifi radio optional, would be handy and could expand use cases. management access for instance.
ARM CPU, RB5009 level for shaping duty.
18-54 give or take voltage range

And the purpose for this product is...
An in-line shaper to keep a backhaul or backup link from falling apart during congestion. Something that you could simply pull the feed cable out of a backup link and plug into the unit, and then run a short jumper to the radio.

Could be bump-in-the-wire or a routed device with routeros.

some use cases:

Even if other shapers are being used, when a backhaul gets saturated fq_codel at this device will be the choke point and supersede other CPE or head end shapers. Let's say that you have a primary link that is a LHG60 good for an aggregate 1Gbps. A backup link that is a Dyna good for an aggregate 300Mbps. When that 60Ghz link fails, the congestion at 300Mbps can make that link fall apart and cause customers to 'feel' like they are down. Strap a 250x50 fq_codel shaper in there and while it wont go completely unnoticed, it will dramatically improve the customer's experience. I'm doing this at a few places now with hAP ac2 units. Only works for slower links because fq_codel performance on this box is a bit slower than I want, plus it's not in an outdoor encloser nor does it have PoE passthrough so I have to make many other accommodations for this to work, but it DOES work and works really well.

Another use case might be on flexible framed backhaul links, such as a Dyna with 300Mbps aggregate but you want to preserve 50Mbps for uploads. The 802.11* scheduler doesn't really do a good job here and causes a bad experience if that link was getting saturated even by some high peaks. 250x50 shaper makes the link 'sane'.

Another use case would be bump-in-the-wire between a user's primary router and their switch. Completely transparent but adding in support for pulling out traffic captures to see network issues and shaping where the head-end router has no support.

Yes! This would be fantastic for so many applications. Light L3HW offload for routing would be a great add as well - set a lower cost route to this shaper device so that if it fails, traffic downstream just flows out the original path(s).

Yes! This would be fantastic for so many applications. Light L3HW offload for routing would be a great add as well - set a lower cost route to this shaper device so that if it fails, traffic downstream just flows out the original path(s).

right, lots of use cases. I would likely have this in the backup path already.

Could also be used as a zerotier entry node since it would have enough CPU to get the job done.

https://mikrotik.com/product/wap_ac

I guess this is 90% of what you want, minus the "POE Bypass part"

https://mikrotik.com/product/wap_ac

I guess this is 90% of what you want, minus the "POE Bypass part"

except crucially the CPU. Otherwise this would do the job.

https://mikrotik.com/product/wap_ac

I guess this is 90% of what you want, minus the "POE Bypass part"

except crucially the CPU. Otherwise this would do the job.

And no PoE pass through. That's a crucial need as well.

Would be handy for our smaller links/sites. We've been using CCR-1016's for this sorta job for a long time now using simple quees / pcq and then feed it back to fiber hand offs upstream.
This would be a niche kinda product but I'd get a lot of use out of it.

A slightly different product would be one with 1 RJ45 10Gbps port (with PoE-in) and one SFP+ port ... if MT ever improves SFP module handling, it would be very useful as ONT / media converter (either demarcation point when used by ISP or as router-on-a-stick when used by clients who already have a good ethernet switch).

Would be handy for our smaller links/sites. We've been using CCR-1016's for this sorta job for a long time now using simple quees / pcq and then feed it back to fiber hand offs upstream.
This would be a niche kinda product but I'd get a lot of use out of it.

Have you used fq_codel? It's crap on TILE, really needs one of the annapurna ARM CPUs, even the IPQ ARMs aren't quite enough if the link is >200Mbps. BUT, RB5009 does a killer job at this.

Also... This could easily be a high powered installer device if it had WiFi. With enough horsepower to run speed tests with good results right from the device. Or as a dmarc device for terminating various tunnel types to a customer as well. Again, the CPU needs are decently high for encapsulation of various tunnels.

I don't know if this box can shape gbit in both directions simultaneously. ? A decent i5 or better middlebox can. Doing a transparent bridge IS a good idea if you cannot do anything else: https://apenwarr.ca/log/20180808

I don't know if this box can shape gbit in both directions simultaneously. ? A decent i5 or better middlebox can. Doing a transparent bridge IS a good idea if you cannot do anything else: https://apenwarr.ca/log/20180808

An rb5009 can do it bi-directional. I basically want an rb5009 in a wAP AC box with PoE passthrough like a mAP. An i5 based box is way to big. Even in a NUC form factor placing it out in the environement will be a struggle. Mikrotik has all the parts and pieces to do this now.

ARM CPU, RB5009 level for shaping duty.

why do you need a general purpose processor if you plan to execute only one function?
shaping is a very simple task, and can be done entirely in hardware.
moreover, most switches have this functionality and run it at wire speed.

ARM CPU, RB5009 level for shaping duty.

why do you need a general purpose processor if you plan to execute only one function?
shaping is a very simple task, and can be done entirely in hardware.
moreover, most switches have this functionality and run it at wire speed.

if the traffic you want to do shaping can be identified only using mac, ip, protocol and/or port number can do by ASIC

But nowadays that can be very limited

More useful traffic shaping involves certain DPI and connection tracking, most ASIC's dont do that, if there is any will be very very expensive

ARM CPU, RB5009 level for shaping duty.

why do you need a general purpose processor if you plan to execute only one function?
shaping is a very simple task, and can be done entirely in hardware.
moreover, most switches have this functionality and run it at wire speed.

You've completely missed the point. fq_codel shaper. This is not a hardware task.

why do you need a general purpose processor if you plan to execute only one function?
shaping is a very simple task, and can be done entirely in hardware.
moreover, most switches have this functionality and run it at wire speed.

if the traffic you want to do shaping can be identified only using mac, ip, protocol and/or port number can do by ASIC

But nowadays that can be very limited

More useful traffic shaping involves certain DPI and connection tracking, most ASIC's dont do that, if there is any will be very very expensive

I don't want need or want any DPI. Just fq_codel. This is an established and functional model. I need want hardware in the right form factor.

Couldn’t you just use the fq_code shaper directly on the dynadish?

Couldn’t you just use the fq_code shaper directly on the dynadish?

CPU is WAY to slow for good results, plus there are a lot of other PTP radios out there.

why do you need a general purpose processor if you plan to execute only one function?
shaping is a very simple task, and can be done entirely in hardware.
moreover, most switches have this functionality and run it at wire speed.

You've completely missed the point. fq_codel shaper. This is not a hardware task.

why do you need fq_codel shaper? it is not as good as you think. it shows good result on icmp latency, but in real life, the latency of tcp sessions almost does not improve.

You've completely missed the point. fq_codel shaper. This is not a hardware task.

why do you need fq_codel shaper? it is not as good as you think. it shows good result on icmp latency, but in real life, the latency of tcp sessions almost does not improve.

uh, I run a substantial wISP and tons of fq_codel shapers in production. It's fantastic.

why do you need fq_codel shaper? it is not as good as you think. it shows good result on icmp latency, but in real life, the latency of tcp sessions almost does not improve.

uh, I run a substantial wISP and tons of fq_codel shapers in production. It's fantastic.

in MikroTik devices?? which references ?

uh, I run a substantial wISP and tons of fq_codel shapers in production. It's fantastic.

in MikroTik devices?? which references ?

mikrotik among other things.