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%. 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.
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. 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. 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=60038&t=60022 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
