Table of Contents
Advertisement
Figure 13: Relative Strict-Priority Configuration
This configuration provides a latency bound for the relative strict-priority queues.
The worst-case latency caused by a nonstrict packet is the propagation delay of a
single large packet at the VC rate. For a 1500 byte frame at a 2 Mbps rate, that delay
is about 6 milliseconds.
This configuration provides for shaping the aggregate of nonstrict and relative strict
packets to a single rate, and it is consistent with the traditional ATM model. It does
not scale as well as true strict priority, because the nonstrict and relative strict traffic
together must not oversubscribe the port rate.
Relative Strict Priority on ATM Modules
You can use relative strict priority on any type of E Series line module; however, on
ATM line modules you have an alternative. On ATM line modules you can configure
true strict-priority queues in the HRR scheduler and shape the aggregate for the VC
in the SAR scheduler. VC backpressure affects only the nonstrict traffic for the VC.
For this type of configuration, you should shape the relative strict traffic for each VC
in the HRR scheduler to a rate that is less than the aggregate VC rate. This shaping
prevents the VC queue in the SAR scheduler from being congested with strict-priority
traffic.
The major difference between relative and true strict priority on ATM line modules
is that relative strict priority shapes the aggregate for the VC to a pre–cell tax rate,
whereas true strict priority shapes the aggregate for the VC to a post–cell tax rate.
For example, shaping the VC to 1 Mbps in the HRR scheduler allows 1 Mbps of frame
data, but cell tax adds anywhere from 100 Kbps to 1 Mbps additional bandwidth,
depending on packet size. Shaping the VC to 1 Mbps in the SAR scheduler allows
just 1 Mbps of cell bytes regardless of packet size.
Comparison of True Strict Priority with Relative Strict Priority Scheduling
Chapter 8: Configuring Strict-Priority Scheduling
63
Advertisement
Table of Contents
Troubleshooting
