Any time you hit a hard policer vs a shaping policer you'll see this sort of backoff in TCP connections; we see similar issues with Telstra policed services. Because the mikrotik queues are a bit more 'bouncy' than an ASIC controlled shaper it works best if you do the calculations to ensure that your local rate won't ever try and burst over the policed limit on the upstream. Good rule of thumb is to keep at 90% for services under 20Mbps and increase slowly up to 100Mbps (where you could conceivably increase to around 96% or 96Mbps). Remember also that if you're performing the rate limiting on the upstream side of the connection, you have more control over the max-limit of the traffic passing into the NBN 'pipe' but less control over the traffic coming back. This also plays into the mix, and may cause you to limit the inbound (upload from the user) traffic to a lower rate than you can deliver out (download to the user) from the CCR terminator. Another thing to look into is ensuring any custom queues aren't creating an artificial bufferbloat issue - http://en.wikipedia.org/wiki/Bufferbloat Food for thought. - Andrew On 26 February 2015 at 10:53, Mike Everest <mike@duxtel.com> wrote:
Hi All!
Earlier this week, I received a report from some guys using CCR to terminate ppp sessions over NBNCo tails and reporting that although fiber services worked perfectly, customers on wireless service continually hit traffic policer with result being download speeds about 1/2 of expected max.
Again this morning, I received similar report from different operator :-( haven't confirmed what routerOS version for either of them yet..
Has anyone else seen this happen? Would setting output limit at client end ease that behaviour?
Any/all comments, suggestions welcome! :-}
Mike.
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au