The only time we saw trouble was when the links were under load. A for instance
is that a 600 mb subrated GigE link would start dropping a significant amount
of traffic for us around 500 mb of load. Adjusting the queue depths corrected
the problem. I'm not sure anyone would actually see this trouble unless the
links in question were under considerable load.
What my reply boiled down to is that a lot of our Engineers spent a very large
chunk of time chasing this down and since the subject of ES20 port queues came
up I figured I'd save someone else that same time if they have similar troubles
while (hopefully) giving folks a better idea of how the queues work on the card.
-Will
----- Original Message -----
From: [email protected]
Sent: Wed, September 30, 2009, 11:16 AM
Subject: Re: [c-nsp] ES20 - Port Queues
Will,
Thanks for the very complete explanation.
I have a similar policy-map attached to the interfaces on the ES20s.
For this particular 1GB link I can see the queue-limit by default is not
sufficient for the bandwidth of 120000k I have for this class.
Class-map: qos-cos4 (match-any)
7403774 packets, 10083940188 bytes
5 minute offered rate 88244000 bps, drop rate 0000 bps
Match: cos 4
Queueing
queue limit 6635 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 7450680/10147826160
bandwidth 120000 kbps
With this queue limit I could only pass 13588k of traffic before tail drops
However I see a 5 min offered rate of 88224k with no tail drops.
Is this because the link is not under congestion?
>From the calculations below I have now set the queue limit manually
120000 x 1000 = 120000000
120000000/8 = 15000000
15000000/256 = 58593.75
Class-map: qos-cos4 (match-any)
12103420 packets, 16484858040 bytes
5 minute offered rate 96063000 bps, drop rate 0000 bps
Match: cos 4
Queueing
queue limit 60000 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 12103420/16484858040
bandwidth 120000 kbps
I also noticed on my priority queue that the queue limit is always set
to 66 packets by default.
I am assuming this is to reduce latency for rtp but by the above logic
that would equal 135.168k before tail drops
and I am seeing 287k with no drops.
queue stats for all priority classes:
Queueing
queue limit 66 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 229339/49963294
Class-map: qos-cos5 (match-any)
229339 packets, 49963294 bytes
5 minute offered rate 287000 bps, drop rate 0000 bps
Match: cos 5
police:
cir 50000000 bps, bc 1562500 bytes
conformed 226069 packets, 49250874 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 286000 bps, exceed 0000 bps
Priority: Strict, b/w exceed drops: 0
I believe you when you say the queue limit could cause drops as the
logic is sound but I can't see any impact from the outputs above. maybe
I' missing something.
Thanks
Anthony
Byrd, William wrote:
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
