MikroTik

i am run on PPPOE for all customers
Can We Make Queues To give all customers 30MB connections speed but when any customers use full bandwidth 30MB continuous for 5 Minutes drop speed to 16MB

i think is best solution to make conniction stable and reliable

https://wiki.mikrotik.com/wiki/Manual:Queues_-_Burst

Can you help me to write rule for this solution

Burst settings to allow a customer to burst ( temp increase bandwidth ) , then when the burst period has timed-out ( finished ) have the customer bandwidth fall back to normal or anything slower is always a bad idea that will create problems for customer connected to an ISP.

A fixed maximum bandwidth setting ( no bursting ) is always better for the customer.

One major reason to not use bursting:

Random Early Detection ( RED ) will allow a video codex ( Netflix for example ) to detect the maximum throughput a data stream can sustain without errors. When the codex has zero errors for a short period of time , the codex will up-shift ( switch to a higher quality of video ) which results in greater bandwidth being used and a better sound and/or better picture quality. When the codex detects there are errors , the codex will down-shift ( switch to a lesser quality of video ) which results in less bandwidth being used and a lessor/poorer sound and/or worse picture quality. Note - you may of seen "buffering" pop-up in the middle of a video stream or suddenly the video temporarely freezes , then is normally followed by the codex down-shifting to something that supports a lesser bandwidth.

When an ISP has bandwidth bursting configured to their customers , many ( if not all ) customers maxing out their accounts for the bandwidth they have purchased will see their video quality get better, then get worse, then get better, then get worse and sometimes see temporarily frozen video ( or suddenly horrible video ) and the process repeats over and over again as the ISP's burst settings kick in and change maximum bandwidth to/from a customer.

The best possible method for a video codex to properly work is to have a constant fixed maximum that does not change ( no bursting configured ). This will allow the codex to use and maintain the best codex which will always result in a consistent and best video quality.

It's pretty easy to lab test this. Just set up a lab customer at 1-Meg and configure bursting to 25+ Meg for 1 to 5 minutes. Yes , these are extreme settings , but you can tweak your burst-and-bandwidth settings and easily verify the video quality results.

North Idaho Tom Jones

When an ISP has bandwidth bursting configured to their customers , many ( if not all ) customers maxing out their accounts for the bandwidth they have purchased will see their video quality get better, then get worse, then get better, then get worse and sometimes see temporarily frozen video ( or suddenly horrible video )

if you configure properly burst-threshold that does not happen

When an ISP has bandwidth bursting configured to their customers , many ( if not all ) customers maxing out their accounts for the bandwidth they have purchased will see their video quality get better, then get worse, then get better, then get worse and sometimes see temporarily frozen video ( or suddenly horrible video )

if you configure properly burst-threshold that does not happen

I will 90-percent disagree with "... if you configure properly burst-threshold that does not happen ... " for the average customer who is sustaining their maximum bandwidth from the ISP.

I believe all the major video-on-demand providers ( Netflix , Paramont & ... ) all use rate shifting codex's ( in their players ) that attempt to deliver the best possible quality video that can be played without Random Early Detections ( RED ). When there are frequent REDs, the codex will down-shift. When there are no REDs, the codex will up-shift.
If we take a typical customer with 2 or 3 smart TVs that are streaming , all three smart TVs and their codex will attempt to deliver the best video a codex can deliver. When a burst period expires ( suddenly lots of RED, the codex on all 3 smart TVs will have to down-shift. So now the RED is magnified by a factor of 3 which then triggers all three smart TV codex drivers to temporarily shift-down then shift-up then shift-down then shift-up untill RED is at an acceptable level a codex on each smart TV can handle.

I've been able to lab test this, and almost every time , when burst is encountered , the codex starts changing almost as soon as the next video packet-buffer is received.
Bursting effects much more than video codecs , it effects all TCP and UDP streams because of changing RED conditions.

IMO - The best ISP policy is to not use bursting. If the customer wants a faster account , then let the customer purchase a faster account ( and have the ISP actually deliver the customer purchased bandwidth 99.9 percent of the time 24-hours a day ).

if you configure the burst-threshold value significantly below max-limit value that do not happen

if you use a burst-threshold value between burst-limit and max-limit is when you end up in the situation you refer to @TomjNorthIdaho