this is beginning to sound like a job for TTCP Check out:
http://www.netcraftsmen.net/id27.htm for information about this process. I know it is supported on Cisco routers, although I've not played with it much. -- TANSTAAFL "there ain't no such thing as a free lunch" ""Priscilla Oppenheimer"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Brett Johnson wrote: > > > > While I agree that upper-layer protocols do add overhead and we > > have to take > > into account the inter-frame gap, I still think I should be > > able to achieve > > greater then 75%. > > I was assuming we were counting all bytes, protocol headers included, in > order to get a network throughput measurement, rather than an application > throughput measurement. The only protocol overhead I was considering was the > ESF framing bits, which to be honest don't amount for much. In fact, if you > use 1.536 Mbps instead of 1.544 Mbps in the denominator, than you don't have > to worry about ESF. But the inter-frame gaps will still byte you, so to speak. > > > Additionally, doesn't the byte count from > > the snmp string > > include the upper-layer protocol bytes? I might be mistaken on > > that, but I > > thought I read that the byte count is accumulated with the > > total packet size > > including data and protocol headers. > > I'm not sure which byte count you're referring to or where you're measuring > it. But you will need to know what it counts in order to determine if you > should get better than 75%. > > What does the load on the router show? That might be a better measurement > for what you're doing? It counts all bytes. > > > > > What I take from the conversation so far is that I should be > > able to achieve > > greater throughput if there are no problems with windowing, mtu, > > retransmissions,.... Since these are test routers I am playing > > with, I will > > make sure there are no issues with them. These were the first > > 3660s I > > played with that have internal CSUs. My thought was using the > > multiple lines > > as one virtual pipe and load balancing through static routes > > was causing the > > problem. > > Multilinking and load balancing could affect the results. Stuff like that > takes processing time during which no bytes are being sent possibly. > > > > > WS---\ _________________T1_____________ > > WS----Switch---Router1_________________T1_____________Router2-----Server > > WS---/ _________________T1_____________ > > > > If I am able to optimize both packet size and window size what > > would be the > > theoretical max throughput I could expect across a T-1 line > > (not taking into > > account end-device issues or switch latency)? This is more for > > my own > > knowledge. > > Strictly speaking, your theoretical max throughput could be 1.536 Mbps. But > it's unlikely you'll achieve that, especially if your testing involves the > workstations, server, switches and router shown in your drawing. If you > could test just from the router, you might be more likely to achieve max > throughput. > > If your concern is what can you expect for your typical applications, then > you should test from the workstations, though. > > The only answer to the question about expected throughput is that you have > to measure it, check out the protocol behavior with an anlyzer or other > tools, do some optimzation if possible, and then do some more measurements. > Theory is useless in this case. It's not theory that you care about. It's > the real-world with all its computer messiness that you care about. > Throughput is a measurment. Don't confuse it with capacity or theoretical > capability. > > And, have a HAPPY NEW YEAR! > > Priscilla > > > > > Thanks for all the responses. > > > > Brett Johnson > > > > -----Original Message----- > > From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, December 31, 2002 1:10 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Built-in CSU capacity [7:60022] > > > > > > Oops. Sorry for the null message. See below for what I really > > wanted to say. > > > > Priscilla Oppenheimer wrote: > > > > > > Brett Johnson wrote: > > > > > > > > I am running a test on two 3660 routers with multiple CSU > > > cards > > > > and > > > > cross-over t1 cables between the two routers. I am unable > > to > > > > exceed 75% > > > > capacity on any t1 no matter how much data I pump into the > > > > router. Below is > > > > a sample config for one of the interfaces, the rest are > > > > duplicates with > > > > different addresses: > > > > > > > > > > > > controller t1 1/0 > > > > framing esf > > > > clock source internal > > > > channel-group 0 timeslots 1-24 speed 64 > > > > > > > > interface serial 1/0:0 > > > > ip address 10.0.0.1 255.255.255.0 > > > > encapsulation ppp > > > > no ip route cache > > > > no ip mroute cache > > > > > > > > ip route 0.0.0.0 0.0.0.0 serial 1/0:0 > > > > > > > > Is there a way to use the full bandwidth (CEF, 7200 router > > > with > > > > CEF and > > > > multiport CSU, external CSUs...) or is this a limit of the > > > > hardware and > > > > setup? > > > > It's partly a limitation of the protocols. To start with, ESF > > uses 8,000 bps > > of your 1.544 Mbps for the framing bits. So you really only > > have 1.536 Mbps > > for data. > > > > Also, upper-layer protocols leave gaps between packets. Sure > > you can attempt > > to send incessant pings with as little gap as possible, but > > there will > > probably be some gap no matter what you do. Try to use frames > > as large as > > the MTU to avoid too many gaps. Don't go above the MTU or > > you'll force IP > > fragmentation which will worsen your results. Try increasing > > the interface > > MTU for best results. > > > > You could try testing with FTP instead of ping, but then you > > would want to > > make sure the TCP window is also maxed out so that the sender > > doesn't have > > to stop and wait for an ACK. With FTP, even more so than with > > Ping, you're > > going to be affected by OS and host hardware constraints, > > however. How > > quickly can the OS get data off the hard drive? How quickly can > > the other > > side flush the buffer? How big is the buffer? How quickly can > > it write to > > the hard drive and ACK? How long does it take to set up the > > control and data > > sessions (3-way handshake?) Is it using slow start. To maximize > > your > > numbers, start recording after the handshakes and slow start. > > > > Also, where are you doing the testing from? Are there > > intermediate devices > > between the end points that are adding some delay, such as > > switches and > > routers, or are you doing the testing right from the router? A > > faster router > > might help. (You asked whether using a 7200 might help and it > > might, but > > probably not much?) > > > > Anyway, we would have to know more about your testing setup to > > know why > > you're only getting 75%, but it's not too unexpected > > considering the typical > > testing setups we all tend to use. > > _______________________________ > > > > Priscilla Oppenheimer > > www.troubleshootingnetworks.com > > www.priscilla.com > > > > > > > > > > > > Thank you, > > > > > > > > Brett Johnson Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=60053&t=60022 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
