cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
730
Views
8
Helpful
11
Replies

thruput of c2811 router

jay77jay77
Level 1
Level 1

for the benchmark testing,connected two c2811 router back-to-back with RJ45 cross cable and used the command TTCP to test the thrughput. One c2811 acting as transmitter and the other acting as receiver. However repeatedly im getting the througput of 3386Kbytes/s. However the theoretical value is 12500Kbytes/s. Im using the tcp window size of 8Kbyte.

Simlar test when run over v.35 bk-to-bk, produces the result nearly equal to 256kbytes/s.

Any advise?

11 Replies 11

Joseph W. Doherty
Hall of Fame
Hall of Fame

You might try increasing the TCP receive window sizes on the routers.

hi

Thks.I have tried setting the ip tcp window size bigger than 65535bytes, but when doing the TTCP, it takes only upto 65535bytes for window size. Any hints on how to set and use a bigger window size that will be used by TTCP. Or is it a limitation that the max window size will be 65535 supported by TTCP?

Tks

I didn't realize TTCP on the router allows configuration of the TCP receive window. I had in mind the global TCP receive window setting for the router, but it, I believe, is limited to 64K. (If TTCP is truly setting the TCP's session's TCP receive window, shouldn't be any need to adjust the router's global setting, but you could try it too.)

Hi, router performances are measured for traffic routed through, not generated traffic.

Moreover, even if using an external ttcp, due to all the windowing issues and limited performances of the PCs, in most cases you will have a bottleneck on the end systems and not the router.

Unfortunately, a professsional traffic generator is needed to measure router performances in volumes of fast ethernet traffic or more.

Hi, router performances are measured for traffic routed through, not generated traffic.

Agreed, a point often overlooked, i.e. the performance differences of a router routing vs. acting as a host.

Moreover, even if using an external ttcp, due to all the windowing issues and limited performances of the PCs, in most cases you will have a bottleneck on the end systems and not the router.

On the slower routers, those which are really unable to forward at 100 Mbps or better rates yet have FastEthernet or GigEthernet interfaces, my experience, I've been able to peg their CPU using a PC. For instance, did so with a 2811 when the question was asked, what would happen if it was attached to a full DS3.

So, the performance of a PC might not always be an issue, however, your point is still well taken when dealing with TTCP and windowing issues.

Unfortunately, a professional traffic generator is needed to measure router performances in volumes of fast Ethernet traffic or more.

Not sure that holds true, again for the slower routers, unless you really need the additional analysis features they also sometimes offer. There are other PC tools beyond TTCP that could be used. For the OP, there's also the performance chart we kick about on these forums, copy attached, that provides some idea of forwarding performance.

Hi Joseph, the thing is that so far I've never found a PC based performance measurement tool that is scalable, accurate and comprehensive enough for my needs.

Look at it this way, an hardware-based perf. and test device it's one of these things that ocne you've tried, you just don't want to do without anymore. Too bad it costs a lot of money.

Of course for small routers one should be able to max out the box with commonly available tools. Still, these don't measure QoS, program traffic patterns, and too many other things that are important for serious testing.

Yes considering host and router function-

Indeed i had tested with three router ie. 2x routers acting as host and one acting as a router. Even in that setup the performance measured was a the same around 3.3Mbytes/sec.

Be reassured is not a problem with the routers. Setup a proper traffic generator and you will be able to see the true performances.

Only now, did I finally notice your measured bandwidth has been in bytes/sec, not bits/sec.

So your issue is you've only achieved 3.3 MBps (or 26.4 Mbps) rather than your "theoretical value is 12500Kbytes/s" or 100 Mbps.

From personal experience and the performance sheet I provided earlier, a 2811 is not likely to provide 100 Mbps of sustained routing forwarding performance. Often there's an assumption that a network device can sustain throughput that corresponds with the bit rate of network interfaces, especially Ethernet interfaces. Often not true unless the device is advertised as "line rate" or "wire speed", etc., capable.

Already touched upon in a prior response, network devices are normally optimized for their network function. Using them as hosts, in your case one as a TTCP sender and the other as a TTCP receiver may result in suboptimal performance. (I.e. this wouldn't impact the middle router in your setup, but the end routers in their role of TTCP hosts might not be able to push TTCP more than the rate you've seen but be able to forward traffic, as a router, at a higher rate.)

Another issue, if the recorded rate you note is from TTCP stats, this probably is the effective TCP transfer rate, not the network transfer rate. The TCP transfer rate shouldn't account for IP/TCP and Ethernet overhead/header's consumption of the 100 Mbps line rate. I.e. such a TCP rate would be less than then the line rate. (How much less depends on the ratio of all the overhead factors relevant to payload. Ratio improves with large packets, sometimes decreases with higher Ethernet bandwidth, which is why there's often jumbo Ethernet on many newer gig Ethernet interfaces.)

Also touched upon in a prior response has been TCP windowing issues, but there are other TCP issues that impact performance; e.g. slow start and the impact of any drops.

Although Paolo is correct, the best performance testing would be accomplished with a designed traffic generator, you might still try a pair of PCs using one of the free or inexpensive traffic generator tools, other than TTCP.

Thanks. And i faced a situation where the guy i worked for said that he is fine with tcp throughput of a 512kbps wan link as his thruput test almost is at 420kbps for tcp.

But when he tested the udp its only about 150kbps to 200kbps?

So what im wondering is will the network treat tcp / upd differently when measuring thruput?

can i also know what is difference of udp thruput and udp streaming thruput?

Tks.

"So what im wondering is will the network treat tcp / upd differently when measuring thruput?"

To a network device, they are both IP packets, so forwarding performance should be the same for either. However, network devices often show a performance difference when dealing with different size packets, so you would need to confirm the packet sizes were alike. Also, this also assumes the traffic wasn't passing through an ACL where performance might also reflect how deep in the ACL the device had to compare before a match was made to allow the packet to be forwarded.

"can i also know what is difference of udp thruput and udp streaming thruput?"

Unclear what you're asking. UDP packets are UDP packets, although the application can decide what they contain and how fast they will be sent. For instance, many streaming applications, like audio or video streams, use a compression method which has an "average" bandwidth usage but actual bandwidth during any particular time interval, i.e. the actual timing and sizing of the packets during a time interval, reflect the signal. For audio, quiet, and for video, quiet with no picture change, may result in small and/or few packets. Audio with many combined sounds or video with a lot of motion may result in large and/or many packets.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: