Home page logo
/

nanog logo 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. 













  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault