Steven Aiello wrote: > > Ok, > > So I know there is a big difference in the cost and > performance of > Cisco (even lower end models) and let say a netgear switch. > But where > do the difference lay? I know that there are memory issues and > back > plain differences in these 2 classes of switches. But how do I > find out > what a lower cost switch will perform like. I was doing some > bench > marking on a NetGear 100Mb switch, between a large file > transfer off a > Win2k Server and a client. The through put was only a few Meg > a best. > The NIC in the server is a Gbit NIC and shouldn't be over > whelmed by a > simple file transfer. (I was running this while every one else > was out > of office so I know that's not an issue). I know that with > Ethernet > there is collisions and the like so I may not get true 100Mb > performance > but the results were horrible.
There shouldn't be collisions if it's all point-to-point full-duplex links, i.e. each switch port just connects one device and is properly configured, as is the end device. Check the configs, but also be aware that throughput != capacity. Put Ethereal on it and see what's really eating the bandwidth and causing delay. Small window size maybe? Slow start? Non-optimized packet sizes? Slow server response? Slow client turnaround with next request? I'll copy and paste a few paragraphs from Troubleshooting Campus Networks on this topic below. > What should I look for even in > lower > cost switches to be sure I get at least decent performance out > of them? Vendors, independent test labs, and trade journals often publish information on the tests they have done to verify the performance of particular network devices. Network World used to do these. Of course, with the sucky economy, maybe there are fewer of these test results published than there used to be... A few places to check, including Network World: � The Interoperability Lab at the University of New Hampshire (IOL). See www.iol.unh.edu for more information. � Miercom Labs. See www.miercom.com for more information. � KeyLabs. See www.keylabs.com for more information. � The Tolly Group. See www.tollygroup.com for more information. Be sure to check other places too. Do a Google. > > Even if you ramble on in this point, GREAT! The more you know > the > better I say. OK, here's some rambling about performance in a TCP-based network: The key question to answer is, "What is the size of the receiver's window when it sends an ACK?" Here are some examples and their significance. The Sender Does Not Approach the Receiver's Capacity When the sender does not approach the receiver's capacity to receive and process bytes, the receiver returns a Window Size (with an ACK) that is set to its original, maximum value. The receiver is able to clear its buffer just as fast as it is able to construct and send the ACK. When the Window Size doesn't change, it is an indication that the reporting station has sufficient communication resources to handle the task. If data packets are acknowledged individually, it indicates that the sending station is not transmitting data very aggressively. Perhaps the data cannot be constructed in large blocks (as in the case when individual data records are retrieved from a database). When the sender completely fills the receiver's window and then stops to wait for an acknowledgment, it can indicate one of two things. One is that the sender has a large block of data queued for transmission (as with a file transfer). The other is that the receiver is busy doing other tasks and can't get clock cycles for processing the received data and constructing the ACK. The Sender Begins to Approach the Receiver's Capacity In our example, the sender is sending 1-KB data segments into an 8-KB window. Imagine that an assessment of the Window Size in successive ACKs looks like this: 8192, 7168, 6144, 6656, 6144, 7168, 7680, 7680, 7168, 8192 Notice that the size of the window is reduced by the received data segments and the receiver is trying to clear the buffer and get the size of the window back to its original value. If you study the sequence of values, you can imagine the receiver struggling against the received data, as if it is a person running up the down escalator in a store. The receiver is working against the continuous stream of received data, and, although it is forced back sometimes, it ultimately manages to return to the fully open window (8192 KB). This is normal behavior of the TCP sliding window. There is nothing wrong here. However, this is an indication that the sender is making the receiver work. In the next example, you'll see what happens when the receiver can't keep up with the sender. The Sender Overloads the Receiver's Capacity With the constant receipt of 1-KB segments into an initial 8-KB window, consider the following Window Size reports in successive ACKs: 8192, 7168, 6144, 6656, 6144, 7168, 7680, 7680, 7168, 6144, 5120, 4096, 3072, 2048, 1024, 1740, 1024, 0 As with the previous example, the receiver is trying to open the window and, periodically, it manages to make some progress. In the end, however, the size of the window is gradually dragged lower and lower, eventually reaching zero. A zero window condition indicates that the receiver in no longer able to receive any data and the sender must stop. Normally, if a zero window condition exists, you will see the window open again after three to ten milliseconds. It is important to realize that when a sender detects a zero window condition it waits until the window is fully open, back to its maximum size, before it recommences transmission. You may see something like the following: First ACK Packet: Window Size = 0 4 millisecond delta time Second ACK Packet: Window Size = 6144 3 millisecond delta time Third ACK Packet: Window Size = 8192 In this case, the total delay before the sender continues transmission is seven milliseconds, plus the transmission time of the three ACK packets. An occasional zero window condition is not a problem; it's a normal part of the memory management process of the TCP stack. However, when the size of the receive window is reduced to zero more than once per Megabyte of data received by a station, then it indicates that the receiver is too slow (doesn't have enough CPU power), overloaded (has too many tasks running), or has insufficient communication buffer memory. (We use one Megabyte of data as a general guideline for measuring the frequency of errors. Problems should not occur more than once per Megabyte of data.) Zero Window at Conversation Start A zero window condition sometimes occurs at the beginning of a new TCP connection, when a server sends a sudden burst of data without following the TCP slow start algorithm. For example, when FTP begins sending a file, it may blast out packets until the receiver's window is full, and then wait for an ACK. The receiver, which didn't know whether it was going to receive small or large quantities of data, must adjust its memory management mechanism to accommodate the received data rate. After the initial blast of data, the receiver may report that the size of its receive window is zero. If the receiver immediately increases the size of the window, then this is not a problem. If the data rate in a conversation suddenly increases dramatically during the course of an established connection, this is another case where a zero window condition can occur. The difference between this normal situation and the zero window overload problem is in the way that the window is reduced to zero. When the window is slowly dragged down to zero, and you can see the recipient struggling to keep it open, that's a problem. When the window suddenly goes straight down to zero as the result of a sudden blast of data segments, and then you see continued transmissions working properly, this is normal memory management behavior. As with any zero window condition, you should be concerned if you observe this happening more than once per Megabyte of data, however. The Stuck Window Situation When the size of the receive window goes below its original maximum value, without reaching zero, and does not return to the maximum value in a timely manner, the window is considered stuck or frozen. WildPackets EtherPeek and AiroPeek expert systems call this a Stuck Window, while the Network Associate's SnifferPRO expert analyzer uses the term Window Frozen. Other expert systems may use different terminology. (An expert system is artificial intelligence software that goes beyond ordinary protocol decoding software to automatically identify and diagnose problem symptoms on a network.) If you see a Stuck Window or Frozen Window symptom with your expert system, you should go to the packet where the problem is reported and then work backwards to identify the flow of sequence and acknowledgment numbers. Watch the shrinking and growing of the recipient's receive window, by looking at the Window Size field that the recipient reports. Determine whether the recipient is struggling to open the window (due to overload) or the window has suddenly decreased (due to memory management). Continue to examine the size of the window after the Stuck Window symptom report. You may see the window eventually return to full size, in which case the data flow is normal. On the other hand, you may see the window remain small for the remainder of the conversation, indicating that an overload is imminent (but not currently impacting the conversation). As long as the window is open (greater than zero), data can flow. Identifying TCP Performance Problems When users observe performance degradation on a network, the question often arises, "Is the problem with the network, or is it the application itself that's slow?" By comparing the response time for TCP acknowledgments with application response times, the source of degradation can be isolated. When a host has a non-zero receive window, its partner should send TCP segments as rapidly as the network and application allow, after getting past the slow start period. When data is received, the TCP recipient sends ACKs. The application program has its own requests and replies. For example, if a client sends an FTP RETR (retrieve) command or an SMTP HELO (hello) command, the server should send a positive reply. If a client sends a Read Request to a file server, the server should send a Read Reply. Application requests and replies may require that data be accessed from a server disk and processed in some manner by the client, which can slow down performance. When assessing performance, you should compare application response times to TCP ACK times to distinguish network and application problems. Consider a situation where a client has just issued a Read Request. TCP must acknowledge the request segment, and the application must also process the request and send back a reply. One of these situations can occur:  The TCP ACK is carried with the application reply. In this case, the application is able to respond just as quickly as TCP is able to acknowledge data. This means that the application is operating at its maximum level of performance. If there is a performance problem, it doesn't lie with the application.  The TCP ACK comes back immediately and the application reply is delayed. This indicates that the network is not the cause of the observed performance problem but, rather, the application is at fault. Because the TCP ACK is able to come back immediately, it proves that the network is working properly.  The TCP ACK is delayed a long time. In this situation, there is a long delay between the original transmission of the application request and the TCP ACK for the TCP segment that carried the request. The delay is longer than the ordinary delayed ACK timer. In this case, the network is suspect. When analyzing sequence and ACK numbers, you need to know where your protocol analyzer is placed in the internetwork with respect to the placement of the client and server in the TCP conversation. If your analyzer resides on the LAN with the client, keep in mind that you may see ACKs that the server never sees. The client may be keeping up, but ACKs are getting dropped in the internetwork somewhere before reaching the server. If your analyzer resides on the LAN with the server, you may see transmissions from the server that never make it to the client. On Cisco routers, you can use the show interface command to see whether routers are dropping packets. If the router seems fine, another possibility is that a WAN or LAN between the client and server is having problems. A WAN service provider could be dropping or inadvertently changing packets. A LAN could be experiencing a high level of collisions (Ethernet), could be beaconing (Token Ring or FDDI), or could be misconfigured for speed or duplex mode. If possible, move your analyzer to different parts of the internetwork or work with a partner who can place an analyzer on the opposite side of the internetwork where you are working. Priscilla Oppenheimer > > Thanks all, > Steve > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=74998&t=74987 -------------------------------------------------- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
