When I run a wireless link test (from SM or AP end) using the Bridging and MIR option, the SM Uplink Bucket depletes at an excessive rate, ie it goes from 2500000000 to zero in under two seconds and then only refils at the CIR rate thereby seriously impacting performance in the subsequent minutes.
If I run a throughput test from a device behind a bridged SM, eg a router with PPPoE session on it, the Uplink Bucket depletes at the expected rate, even though I am getting very similar performance results.
If I monitor a Natted SM with high throughput, the Uplink bucket also appears to deplete at an excessive rate though this is only anecdotal as I have not yet been able to test conclusively.
When I run a wireless link test (from SM or AP end) using the Bridging and MIR option, the SM Uplink Bucket depletes at an excessive rate, ie it goes from 2500000000 to zero in under two seconds and then only refils at the CIR rate thereby seriously impacting performance in the subsequent minutes.
If I run a throughput test from a device behind a bridged SM, eg a router with PPPoE session on it, the Uplink Bucket depletes at the expected rate, even though I am getting very similar performance results.
If I monitor a Natted SM with high throughput, the Uplink bucket also appears to deplete at an excessive rate though this is only anecdotal as I have not yet been able to test conclusively.
Lightnet_Barry,
You are correct when a Link Test is run the Burst Bucket for that SM is purposefully emptied. So it will go back to filling it's bucket at the MIR (not the CIR as you said).
I think this is a bug. I think we should only clear out the Burst Bucket if running "Link Test with Bridging MIR" so the test checks if can hit the MIR. Other Link Types should not mess with the Burst Bucket.
In the meantime the only work around is not to run Link Test on customers with Burst Buckets during times when they are needing to use the Burst Bucket.
Thanks for bringing this up. We will try to get in a fix for this ASAP.
When I run a wireless link test (from SM or AP end) using the Bridging and MIR option, the SM Uplink Bucket depletes at an excessive rate, ie it goes from 2500000000 to zero in under two seconds and then only refils at the CIR rate thereby seriously impacting performance in the subsequent minutes.
If I run a throughput test from a device behind a bridged SM, eg a router with PPPoE session on it, the Uplink Bucket depletes at the expected rate, even though I am getting very similar performance results.
If I monitor a Natted SM with high throughput, the Uplink bucket also appears to deplete at an excessive rate though this is only anecdotal as I have not yet been able to test conclusively.
Hi Lightnet_Barry,
I've made a fix in the 16.0 release to address the wiping of the burst bucket credit when running Link Test with MIR. It should now be wiped at the start of the test, but restored after the test completes, back to the original amount that was present before the test started. This should address your main concern of wiping the client's burst credit, resulting in reduced performance after the test.
The way the test was desigined, it is meant to test that the base MIR rate is being reached/capped, and in order to do that, we have to ignore the burst credit accumlated for the duration of the test. Unfortunately, this does not allow you to test that the Burst Rate is being reached when the Burst Bucket has an accumulation of credit. If this is the behavior you expected, that would require a new test or a setting that allows you to ignore/use burst credit. That's not currently on our radar, but could be if enough customers think it would be worthwhile.
Keep an eye out for the next 16.0 BETA to address your primary issue, which will be officially fixed in 16.0.