RouterOS 6.19 - could it be the solution CCR users have been waiting for?
In case you missed it, latest version of 6.19 includes fixes explicitly designed to address general queue problems with CCR models: NOTE: in this build we applied a patch that should solve most of the queueing related performance issues on CCR. If these changes will provide positive feedback we will consider to put them into release of 6.19. Please, test queues on CCR and report results and any problems you might find. It also brings improvements for long term stability of the CCR. They consider this a very important update, and so are also seeking feedback where possible - good AND bad! ;-) Cheers, Mike.
HI Mike, just for the record though, this problem with simple queues happens on everything I have used, for example we have a number of 2011's out there and simple queues drop packets and start queuing packets well before they fill up, I just observed one queuing and dropping packets on a 10M queue when the traffic was at 1M, then at 4M, it dropped them like hot potatoes, it causes all sorts of problems with VOIP too. This router has a custom queue type setup for the queues, it's a PFIFO type with a 200 packet queue, it shouldn't drop a packet unless that queue is flat out. I think it's more noticeable on the CCR's or higher speed queues more than lower speed ones as it's just almost impossible to get anywhere close to the high speeds before the queue drops it's backside out. Perhaps I might try the RC version on this 2011, I am cautious though with the amount of bugs MT seem to be introducing lately. Regards Paul -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Sunday, 10 August 2014 3:19 PM To: public@talk.mikrotik.com.au Subject: [MT-AU Public] RouterOS 6.19 - could it be the solution CCR users have been waiting for? In case you missed it, latest version of 6.19 includes fixes explicitly designed to address general queue problems with CCR models: NOTE: in this build we applied a patch that should solve most of the queueing related performance issues on CCR. If these changes will provide positive feedback we will consider to put them into release of 6.19. Please, test queues on CCR and report results and any problems you might find. It also brings improvements for long term stability of the CCR. They consider this a very important update, and so are also seeking feedback where possible - good AND bad! ;-) Cheers, Mike. _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Monday, 11 August 2014 12:18 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] RouterOS 6.19 - could it be the solution CCR users have been waiting for?
HI Mike, just for the record though, this problem with simple queues happens on everything I have used, for example we have a number of 2011's out
and simple queues drop packets and start queuing packets well before they fill up, I just observed one queuing and dropping packets on a 10M queue when
traffic was at 1M, then at 4M, it dropped them like hot potatoes, it causes all sorts of problems with VOIP too.
This router has a custom queue type setup for the queues, it's a PFIFO type with a 200 packet queue, it shouldn't drop a packet unless that queue is flat out.
I think it's more noticeable on the CCR's or higher speed queues more than lower speed ones as it's just almost impossible to get anywhere close to
high speeds before the queue drops it's backside out.
Perhaps I might try the RC version on this 2011, I am cautious though with
Hi Paul, Fair comments. The bugs are apparently introduced mainly by linux kernel patches that they are introducing into their code to try to make the most of multi-core functionality. My understanding is that they are walking a tightrope between wasting performance /capability/ of CCR hardware and unleashing a swag of untested kernel patches to routerOS users. I believe that they take each kernel patch on case by case basis and as far as I can tell, there is a fair bit of internal argy-bargy before any one of them is applied to routerOS ;) I guess that the point here is to recognise that when new bugs are introduced, it is not simply sloppy coding or poor testing - it is also calculated risk as to whether new potential of kernel patch outweighs potential dangers ;) So long as we keep that in mind when considering upgrade to production systems, then we can mitigate our own risks :-} Cheers, Mike. there the the the
amount of bugs MT seem to be introducing lately.
Regards Paul
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Monday, 11 August 2014 12:18 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] RouterOS 6.19 - could it be the solution CCR users have been waiting for?
HI Mike, just for the record though, this problem with simple queues happens on everything I have used, for example we have a number of 2011's out
and simple queues drop packets and start queuing packets well before they fill up, I just observed one queuing and dropping packets on a 10M queue when
traffic was at 1M, then at 4M, it dropped them like hot potatoes, it causes all sorts of problems with VOIP too.
This router has a custom queue type setup for the queues, it's a PFIFO type with a 200 packet queue, it shouldn't drop a packet unless that queue is flat out.
I think it's more noticeable on the CCR's or higher speed queues more than lower speed ones as it's just almost impossible to get anywhere close to
high speeds before the queue drops it's backside out.
Perhaps I might try the RC version on this 2011, I am cautious though with
HI Mike, I totally agree with what you are saying in that there is risk applying these patches and that it's not really their system which is having the issues but a third party one, or the base OS as is the case here, what I would like to see is something, if possible, where they could at least give us a hint if they have an idea of where problems may arise, from our perspective it's a risk just upgrading ROS unless you have a specific need to address something that is covered by the changelog, even then it can be a bit of hit and miss as to what you might get. When trying to address a problem in a production system and that problem has been identified as being addressed in an update I think any normal person wouldn't expect anything untoward happening when they apply that update, of course this is the real world and it can't be perfect all the time. I for one love the Mikrotik product and wish I could use it for everything, but as our network grows and becomes more complex I find myself asking the question of "which cisco or juniper should I put in here as I just can't quite trust a Mikrotik device for this critical job" more than I used to. Regards Paul -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Mike Everest Sent: Monday, 11 August 2014 1:07 PM To: 'MikroTik Australia Public List' Subject: Re: [MT-AU Public] RouterOS 6.19 - could it be the solution CCR users have been waiting for? Hi Paul, Fair comments. The bugs are apparently introduced mainly by linux kernel patches that they are introducing into their code to try to make the most of multi-core functionality. My understanding is that they are walking a tightrope between wasting performance /capability/ of CCR hardware and unleashing a swag of untested kernel patches to routerOS users. I believe that they take each kernel patch on case by case basis and as far as I can tell, there is a fair bit of internal argy-bargy before any one of them is applied to routerOS ;) I guess that the point here is to recognise that when new bugs are introduced, it is not simply sloppy coding or poor testing - it is also calculated risk as to whether new potential of kernel patch outweighs potential dangers ;) So long as we keep that in mind when considering upgrade to production systems, then we can mitigate our own risks :-} Cheers, Mike. there the the the
amount of bugs MT seem to be introducing lately.
Regards Paul
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Hi Paul,
-----Original Message----- I for one love the Mikrotik product and wish I could use it for everything, but as our network grows and becomes more complex I find myself asking the question of "which cisco or juniper should I put in here as I just can't quite trust a Mikrotik device for this critical job" more than I used to.
That is perfectly fair - I would argue that it should be a question asked in all cases by default, and for all vendor products also! :-) There is no 1 size fits all approach with MikroTik and the same can be argued for any other vendor hardware I can think of - in many ways: do I trust it to do the job? is the additional expense worth the extra capability? Is the savings in price worth the reduction in performance? Is the additional support level worth the additional cost? ... ;-) Cheers, Mike.
I have to say I sometimes kick own-goals on the issues I encounter because of a new feature or an improvement offered in an update. I feel that, and maybe I'm the only one, maybe not.. I will get to specific "stable" version and mitigate the one or two issues we know about until a newer more promising version comes along and then make the jump after a few weeks testing but run into one or two new issues that I don't yet know how to mitigate, so when the next release comes promising a fix for those I jump ahead again and find myself stuck close to the bleeding edge releases because I don't have our workaround and have come to rely on the features in the newer versions too much to go back to that old stable. Then there are the other people (some others on this list) who will make do with a v5.14 or v5.26 release all this time because it's the best that's come out, the issues with it are known but are still eagerly waiting to see what v7 will bring :-) - Andrew On 11 August 2014 13:49, Mike Everest <mike@duxtel.com> wrote:
Hi Paul,
-----Original Message----- I for one love the Mikrotik product and wish I could use it for everything, but as our network grows and becomes more complex I find myself asking the question of "which cisco or juniper should I put in here as I just can't quite trust a Mikrotik device for this critical job" more than I used to.
That is perfectly fair - I would argue that it should be a question asked in all cases by default, and for all vendor products also! :-)
There is no 1 size fits all approach with MikroTik and the same can be argued for any other vendor hardware I can think of - in many ways: do I trust it to do the job? is the additional expense worth the extra capability? Is the savings in price worth the reduction in performance? Is the additional support level worth the additional cost? ... ;-)
Cheers, Mike.
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
Indeed - you are definitely not alone in that! :-D
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Cox
Then there are the other people (some others on this list) who will make do with a v5.14 or v5.26 release all this time because it's the best that's come out, the issues with it are known but are still eagerly waiting to see what v7 will bring :-)
I lean very close toward /that/ end of the scale - the border router in our DC is running on 5.24, and that is where it will stay until either I need a new router, or want to use a new feature *really* badly! ;-) There are many advantages of this position, not the least is 381 days uptime :) Cheers!
Likewise; core devices still sit on v5.14 v5.24 or v6.4 depending on where we got to with stability testing; and edge devices sit between v6.10-v6.17 depending on the device model and redundant devices available onsite for failover. - Andrew On 11 August 2014 14:33, Mike Everest <mike@duxtel.com> wrote:
Indeed - you are definitely not alone in that! :-D
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Cox
Then there are the other people (some others on this list) who will make do with a v5.14 or v5.26 release all this time because it's the best that's come out, the issues with it are known but are still eagerly waiting to see what v7 will bring :-)
I lean very close toward /that/ end of the scale - the border router in our DC is running on 5.24, and that is where it will stay until either I need a new router, or want to use a new feature *really* badly! ;-)
There are many advantages of this position, not the least is 381 days uptime :)
Cheers!
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
participants (3)
-
Andrew Cox -
Mike Everest -
Paul Julian