That isn't quite true about all Hi Priority traffic going before Low Priority CIR... Leaving Hi Priority MIR at 0/0 is useful if you set a Low Priority CIR, in that case the LP CIR will be honored, then it will move to High Priority traffic.
Recall that the priority order proceeds as follow: HiPri CIR LoPri CIR Bcast CIR (in downlink) HiPri Remainder (beyond HP CIR, up to HP MIR/Burst) LoPri Remainder (beyond LP CIR, up to HP MIR/Burst) Bcast Remainder (beyond Bcast CIR, in downlink) CIR is done in hardware, MIR is done in software, so CIR does count against MIR. The broadcast channel is shared in downlink, so that is why there is a CIR for that data but only in downlink. In uplink, broadcast data is user data so it will follow whatever priority is determined from the packet. Regards, -Aaron -----Original Message----- From: Af [mailto:af-boun...@afmug.com] On Behalf Of Brian Sullivan Sent: Wednesday, April 20, 2016 11:43 AM To: af@afmug.com Subject: Re: [AFMUG] High Priority Uplink / Downlink Timothy, The Sustained rate is is in kbps and the allocation is in kbits. Could you give me an example or screenshot of your QOS (Session Status > Configuration) settings so I can better understand? Also on George's response, "The scheduler will still prioritize HP traffic if you leave it at 0/0. The same applies if you're putting more traffic into it than you have configured. All HP traffic goes before LP CIR and MIR anyway. I think Matt or Aaron explained it roughly this way before. " That sounds like a bug in the QOS scheme, do you know where it was explained like this? Or could Matt or Aaron @ Cambium please elaborate? On 4/19/2016 2:44 PM, Brian Sullivan wrote: > must set the Sustained Uplink/Downlink Data Rate and the > Uplink/Downlink Burst Allocation to be the same
