nanog mailing list archives
RE: Cisco DS3 performance specifications
From: "David Sinn" <dsinn () microsoft com>
Date: Tue, 8 May 2001 12:36:24 -0700
Any multiport cards on the GSR can have a port blocking problem if one port is oversubscribed. This is regardless of engine, or memory on that card (though memory gives you more breathing room). By default there are no queue limits for a given port on a multiport GSR card. So if you have a port that is in a consistent state of over subscription, and thus packets are backing up in the local TX buffer, that port can eat all of the memory and starve the other ports off. It does not matter what processor is doing the switching (and regardless, the processor *for the most part* does not touch any of the traffic in the outbound direction anyways). One should be cognizant that E0's have around 400kpps of forwarding performance, E1 ~700, E2 up to 4Mpps, and E4 up to 25Mpps, which is shared among the ports on the card, so plan accordingly for the traffic patterns you are expecting to se). The most simple fix for this is to set a hard TX queue limit for each port. Thus any one port can only buffer x number of packets, and not starve off the other ports (things can be less then optimal picking x since there are at least four pools for a packet to sit in, and you don't get to define a number for each, just a sum). This also insures you aren't holding packet too terribly long (TCP should be doing it's job anyways...). WRED is another manner, and it is arguable if it is any more intelligent then setting a hard limit to WHAT packet gets dropped. WRED requires more configuration, and is a little more graceful since it will start dropping sooner. Hopefully this will make your traffic curve closer to line rate then the saw-tooth you would expect to see with TX queue limits. David -----Original Message----- From: Neil J. McRae [mailto:neil () DOMINO ORG] Sent: Tuesday, May 08, 2001 8:45 AM To: Bill Thomas Cc: nanog () merit edu Subject: Re: Cisco DS3 performance specifications The cards are engine 0 and there is no hardware switching - I've seen issues on this card - one port has heavy load and the other ports start dropping packets, WRED helped with this but not by much. I'd be interested in your tests. Regards, Neil.
To any and all in earshot, I am engaged in setting up a sytems level test lab for the purposes of measuring among other items, DS3 performance and interoperability between Cisco
12000
series and several new and emerging edge switch devices. In order to set a baseline for performance expectations, I am
attempting to
gather historical data on earlier testing. The nasty rumor I am hearing is that Cisco DS3 interfaces at best
deliver 50
- 60 % throughput. This is supposedly attributed to the way they apply their Traffic
Shaping
and Policing at the port level. I need to obtain documentation that either validates this, or presents
the
correct information. Many of the edge devices involved in the testing, support high levels
of
throughput even at the channelized subrate. An increased need to buffer the data,
to
compensate for a potential mismatch in bandwidth capabilities, would just add to
the
latency and sour the testing. Any and all information is valued and appreciated.
Current thread:
- Cisco DS3 performance specifications Bill Thomas (May 08)
- Re: Cisco DS3 performance specifications Neil J. McRae (May 08)
- <Possible follow-ups>
- RE: Cisco DS3 performance specifications David Sinn (May 08)