Alcatel-Lucent 7450 Quality Of Service Manual page 386

Service SAP QoS Policy Command Reference
amount decremented from the bucket is a function of the amount of time that has elapsed since the last
bucket update and the queue's shaping rate (PIR). If the queue's shaping rate is configured as 1Mbps
and 1ms has elapsed since the last bucket update, the system will decrement the PIR bucket by 125
bytes. One caveat is that the bucket cannot be decremented past a depth of 0. This fact drives how the
system chooses which BCG is used to manage the queue bucket update interval.
If a queue's shaping rate is 1Mbps and the threshold (burst limit) is set to 10Kbytes, the maximum
amount of time that can expire before the queue is updated without resulting in a negative bucket depth
is 81.92ms. This can be calculated by taking the number of bits represented by the bucket depth
(10Kbytes = 10 * 1,024 * 8 = 81,920 bits) and dividing it by the rate (81,920 bits / 1,000,000 bits per
second = 81.92ms). The queue will not be removed from the scheduler until the PIR bucket depth has
equaled or exceeded the configured burst threshold, so the bucket will be at least 10Kbytes deep. If the
system visits the queue PIR bucket within 81.92ms, the resulting decrement operation will leave the
bucket. If the system takes longer than 81.92ms, the decrement result will be greater than 10Kbytes
and part of the decrement result will be lost. The net result is from less than timely updates is that the
queue will not be returned to the scheduler context fast enough and some shaping bandwidth for the
queue will be lost (underrun the shaping rate).
Each Q2 based forwarding plane maintains 7 Burst Control Groups, each targeting a certain queue
bucket visitation time. A 40ms, 20ms, 10ms, 5ms, 1ms, 500us and 100us BCG is supported. By
default, queues are placed on a BCG based on shaping rate and the queue's burst limit (PIR threshold
depth) is set based on the BCG visitation time and the queue's specified shaping rate. When all shaping
queues on a Q2 are left in a default burst tolerance management state, the system has sufficient BCG
visitation resources to ensure that all queues do not experience inaccurate bucket decrement
conditions.
When explicit burst-limit threshold values are defined for a shaping queue, the system picks an
appropriate BCG based on the queue's configured shaping rate and the explicit threshold to find a BCG
with the best target visitation time that results in worst case decrement values that are less than the
configured threshold. However, when a queue is placed on a 'faster' BCG, more visitation resources
are consumed and it is possible that the system will not meet a queue's decrement constraints.
The show qos bcg command allows visibility into a BCG's historic and current visitation time. The
system samples the amount of time it takes each list to visit each of its associated queues once each
second and stores the last 10 samples. It also keeps the longest visitation time seen since the last time
the BCG statistics were cleared, the longest visitation time for the current queue-to-BCG lists
associations, calculated longest visitation time based on maximum scheduling bandwidth and lastly the
longest visitation time for an optionally defined scheduling rate.
With each sample, the system indirectly calculates the amount of scheduling bandwidth based on how
much Q2 resources were diverted from BNG visitation processing. This calculated scheduling
bandwidth is useful since it can be used to evaluate the worst case longest visitation times for each
BCG. The calculated scheduling bandwidth value is stored with the longest seen visitation time and
the longest seen visitation time with the current queue-to-BCG mappings.
Parameters burst-control-group-name — The burst-control-group-name is required and specifies which
386
globally unique Burst Control Group will be displayed. If the specified Burst Control Group
does not exist, the show command will fail and the system will return 'The specified BCG
does not exist'.
Quality of Service Guide