The point here is that it NEVER manages more than about 30-50% of the ingress rate set. You can achieve the speeds if you set them 2-300% above what you want to achieve. This is also not consistent, but varies.
This should be easy to replicate in LAB, tried with both CRS317 and CRS326 and got the exact same problems (both with ROS 6.48.6, 7.7 and 7.. If set to 305M tests show 70-130M, to achive 300 Mbit we have to set the ingress rate to 810M.
This smells like a bug, since it is not the CPU that is the bottleneck here.
It also doesn't seem like there are hardware-related problems, since you can work around it. We offer speed classes of 90/90 Mbit, 300/300 Mbit, 600/600 Mbit and 1000/1000 Mbit. The lowest and highest speed class is no problem. The problem is the shaping of 300 Mbit where we have to shape to 810 Mbit, while on 600 Mbit there is no workaround, there you have to drop shaping.
Mikrotik will not acknowledge this as a bug but says "Yes, we understand and this is how ingress policer works at the moment, as i described in the last email. we will try to improve the ingress policer in future, but I cannot provide a release date."
Since we achieve correct speeds when we set the shaping to completely different speeds, MikroTik should be able to fix this, right?
Has anyone else found a workaround for these issues?