This document discusses the use of the
queue-depth and queue-depth
low-latency commands on the NM-1A-OC3-POM network module on the
Cisco 3800 platforms to reduce or increase latency out of an ATM Permanent
Virtual Circuit (PVC). The queue-depth command is
introduced in Cisco IOS® Software Release
12.4(7.24)T and later. The latency issue arises when there is a low bandwidth
and a burst in traffic occurs during a surge. Refer to Cisco bug ID
CSCsd73749
(registered customers only)
and Cisco bug ID
CSCsj97952
(registered customers only)
for more information on the two different
types of latencies can occur in a customer scenario.

On ATM line cards, the Segmentation and Reassembly (SAR) mechanism has
a queue for each PVC. These two thresholds are associated with each PVC queue:

high watermark

low watermark

The high watermark defines the number of cells that the queue can hold.
The watermark values are used to apply a flow control mechanism between the
host and the SAR on the NM-1A-OC3-POM network module. When cells start to back
up in the SAR, the SAR sends a notification to the host as soon as the queue
inside the SAR builds up to a high watermark. At this point, the VC is marked
as throttled and packets start to back up in the Cisco IOS software hold
queues. At the same time, the SAR drains out the packets. When the SAR reaches
the low watermark, another notification is sent to the host. The VC is marked
as "Open" and traffic to the VC resumes. The problem is caused by the low
values that are configured for the high and low watermarks on the SAR.

Traffic that is processed by PVCs with bandwidth values lower than 10
Mbps on an NM-1M-OC3-POM network module might encounter large latencies. In
such cases packets might be dropped from the output queue.

When you want to better control priority queuing latency or have better
TCP performance, modify the watermark values for each ATM variable bit rate
(VBR) VC by using the queue-depth command. If you
need to change the watermark values, follow these guidelines:

A higher value of high watermark translates to a higher queue
build-up within the SAR and results in a higher latency for latency sensitive
(LLQ) type traffic.

Once the packets are queued in the SAR, they are all treated the
same.

Higher queues inside the SAR give IOS less chance to load latency
sensitive traffic to the SAR. This increases overall latency experienced by
latency sensitive traffic. Hence, in the case of LLQ, higher values of high
watermark are not desirable. However if the high watermark value is too low,
you sometimes end up in situations where each incoming packet causes high and
low watermarks to be hit which causes the VC to toggle between the Open and
Throttled states and too frequently gives rise to large latencies (Cisco bug ID
CSCsd73749
(registered customers only)
). See the Example
Scenario section for more information.

Do not configure the low watermark value to be equal to the high
watermark value because this defeats the purpose of the flow control mechanism.
Even though the queue-depth command allows a high
watermark value up to 65535, it is not recommend that you configure such a high
watermark value. A high watermark value translates into queues within the SAR.
How high the value of the high watermark can be is defined by the SAR memory.
For example, with 1024 VCs, when the high watermark is configured for more than
400 cells, the SAR might run out of memory. This causes packet drops to occur.
As a rough guideline, default values of high and low watermarks for PVCs with a
bandwidth of less than 1 Mbps are 50 and 10. Latency / drop issues can occur
with these values. However, when you multiply these values by a factor of 4 via
the queue-depth command such that the new values are
200 and 40, the symptom no longer occurs.

When a large file of size greater than 60 MB is copied with the use of
the Windows file transfer (PC-to-PC drag and drop / best- effort traffic), the
priority class traffic gets delayed and experiences high latency values. At the
maximum, the latency can reach 100 ms with average hovering around 60 ms. Refer
to Cisco bug ID
CSCsj97952
(registered customers only)
for more information

A new shaping mechanism is introduced in the driver level in order to
fix this issue. Each VC is given a credit in bytes and whenever a packet is
sent the credit is decremented. The credit is replenished every 16ms and the
credit value is set as the number of bytes that can be transmitted in 25ms (scr
*25/8). The value 25ms is arrived after the testing of various PCR values and
credit values. A new CLI queue-depth low-latency is
introduced in order to enable this feature. This is only available on CBR and
VBR class VCs and the bandwidth should not be greater than 10000kbps (10GB).

Note: When queue-depth low-latency is
configured, the queue-depthsis set to 50 and 10. Even if the user configures
other values it does not take effective. Once the user removes the
queue-depth low-latency command the previous
configured values are set. If user has not configured any values, the default
values are set.

If the traffic carried consists of very large packets or is bursty,
this problem is more likely to happen. If the problem persists even after you
increase the high and low watermarks, then it is probably due to
oversubscription.