Chuck, Were you asking about upgrading a router or selecting a new router as part of a design. If it's upgrading, then the last sentence of Steve's message is a good answer. If there are full Qs and/or Q drops when link utilization isn't maxed out, then the router itself is probably the bottleneck. Q drops when utilization is maxed out, on the other hand, are an indication that you need more bandwidth, regardless of the router model.
Selecting a new router that will not be a bottleneck is a much harder problem. You can't look at Q drops because you don't have the router yet! In that case, a few options are to look at vendor specs for packets per second ratings, independent benchmark measurements, trade rag reviews, and the like. For more scientific answers, you could try a modeling programs. Some of them actually have router specs built in and can do a pretty good job of modeling what you will really see. As Steve said, there are many categories of delay, some of which the router "horsepower" can't affect. Here's my taxonomy of delay types: Propagation Delay. Network signals experience propagation delay resulting from the finite speed of light, which is 300,000 kilometers per second, or 186,282 miles per second. These values are for light traveling in a vacuum. A signal in a cable or optical fiber travels approximately 2/3 the speed of light in a vacuum. Serialization Delay. Another fundamental cause for delay is the time to put digital data onto a transmission line, which depends on the speed of the line. Serialization delay is a major factor for low-speed serial lines. It is not much of an issue for high-speed interfaces. Packet-Switching Delay. Packet-switching delay refers to the latency accrued when bridges, switches, and routers forward data. The latency depends on the speed of the internal circuitry and CPU and the switching architecture of an internetworking device. The delay can be as small as 10 to 20 microseconds for 64-byte Ethernet frames crossing high-end switches or routers that have hardware ASICs that handle the forwarding of frames. Queuing Delay. Packet-switching delay may include queuing delay when a packet switch needs to queue data because an output buffer or interface are busy. The number of packets in a queue on a packet-switching device increases exponentially as utilization on an output port increases. Priscilla Steve Dispensa wrote: > > On Sun, 2003-01-05 at 15:52, The Long and Winding Road wrote: > > > Some of us are just debating whether or not CPU utilization > is the "best" > > measure. Over what period? What other factors might be best > brought into the > > mix of factors to consider? > > I'm a big fan of delay as the key performance metric for a > link/router > combination. In the simple case where you're just using a > router to > push IP packets up and down a pipe (leaving out time-sensitive > stuff, > QoS, etc), the real question is delay. In particular, queue > depth is > probably the most accurate measure of link performance. I've > been > hoping for better queue depth measurement tools in IOS (and > other > routers) for a while. > > There are two significant kinds of delay - transmission and > queuing > delay. The first one is obvious - it takes a bit X ms to get > from one > side of the pipe to the other. The second is a wastebasket > category for > everything else that causes delay, including processing time, > CPU > utilization, coding delay, and link utilization. > > You can indirectly measure queue depth by looking at ping > times, but > that doesn't get you directly at the real issue. You know a > link is > instantaneously highly utilized when it starts dropping packets > off the > back of the queue, etc. > > Also, this is complicated a bit by predictive dropping > algorithms (RED, > etc), and by out-of-order queuing like WFQ. > > There are lots of reasons that CPU is bad - think ASICs for > starters, > not to mention offloaded processing that happens in every > variant of > every major router these days. Also, re-calculating LS > databases or > running BGP path vectors doesn't have to impact switching > performance, > even though it can peg the CPU. > > Bits in/out isn't as much a performance metric as a utilization > metric. > You have no idea what the performance was like for those bits, > unless > you guess by inferring that the link was "pretty full", or > something. > > MRTG-style utilization plots miss out on a lot of important > detail too, > because they take the bits in/out problem and make it worse by > only > reporting on it every 5 minutes. > > So, the bottom line is this: If you're seeing large queue > depths and/or > queue drops paired with a less-than-full link utilization over > corresponding periods of time, it's time to upgrade the > router. > > -sd > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=60450&t=60445 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
