Hi all, The presentation Jason mentioned was by TasmaNet, with me presenting :) MikroTik recorded it and you can view it here: https://youtu.be/DipIAJyOxJM It's about 49mins long. Feel free to ask me any questions you have about it. Regards, Philip Loenneker | Network Engineer | TasmaNet 40-50 Innovation Drive, Dowsing Point, Tas 7010, Australia P: 1300 792 711 philip.loenneker@tasmanet.com.au www.tasmanet.com.au -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Paul Julian Sent: Friday, 14 December 2018 5:01 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] QOS Hmm, interesting, OK I will dig that out. Thanks Paul -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Jason Hecker (Up & Running Tech) Sent: Friday, 14 December 2018 4:59 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] QOS Have a look at the Tasmanian ISP talk from the May MUM. They mentioned something about needing to adjust the token bucket sizes as well to keep the bitrate tolerances within NBN requirements. You have a few knobs to play with to improve your QOS. Good luck... I think experimentation on the way to understanding is the only way to go. On Fri, 14 Dec 2018 at 16:42, Paul Julian <paul@buildingconnect.com.au> wrote:
Hi all, how many people actually implement a QOS design within an ISP network which is for data heading from a DSLAM or router TO the customer ?
I am interested to know of those that do are you dynamically managing the QOS using prioritisation of packets or are you hard setting speeds in multiple queues to manage the VOIP quality heading to the customer ? We have written a system which dynamically prioritises packets to the customer, it tears down the default queue created at PPPOE login time and then builds a new queue structure with a parent and two children, one for VOIP and one for everything else.
It works very well, however the Mikrotik priority system is a little slow in reacting sometimes for VOIP and we still see some packets not getting through in front of a large download which is smashing the connection for example.
We can obviously reduce traffic bandwidth in the non-VOIP queue but that would be a permanent thing so even when there was no VOIP traffic they still wouldn't see maximum bandwidth.
We know how to handle both scenarios but I am just interested in how others handle it or whether they do it at all....
Regards Paul _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
-- <https://www.upandrunningtech.com.au> _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au