01-18-2012 05:39 AM - edited 03-04-2019 02:56 PM
Hello
I have two remote routers - and i need to test WAN link between them. No access to other devices.
I've tried to use ttcp, but it does not allow to set TOS and i can not test my QOS policies.
Moreover ttcp seems to have so poor throughput, example (on receiver):
router#ttcp
transmit or receive [receive]:
perform tcp half close [n]:
receive buflen [8192]: 65000
bufalign [16384]: 65536
bufoffset [0]:
port [5001]:
sinkmode [y]:
rcvwndsize [4128]: 16384
delayed ACK [y]:
show tcp information at end [n]:
ttcp-r: buflen=65000, align=65536/0, port=5001
rcvwndsize=16384, delayedack=yes tcp
ttcp-r: accept from x.x.x.x
ttcp-r: 122395000 bytes in 600508 ms (600.508 real seconds) (~198 kB/s) +++
But there should be 10Mbit/s....
Why ttcp has so poor performance ?
Is there any tool on router to test performance ? (extended ping is not enough for >10Mbit/s links)
Thanx
Solved! Go to Solution.
01-18-2012 12:22 PM
yes, sure in CEFswitching on the forwarding path, but TTCP doesn't use CEF, it's a CPU based process which generate packet stream, with CEF it has nothing to do.
01-18-2012 01:39 PM
just to info, on a c7200 NPE-G1 I could reach with TTCP about 30-40 mbits/s but CPU was 100%
multiple ttcp's could be really helpful if CPU load doesn't reach 100%
01-18-2012 05:46 AM
don't forget that TTCP uses the routers CPU which is normally quite slow, if your router has some kind of hardware assistance. You can check the CPU load during the TTCP session to see it.
and try to activate "ip tcp path-mtu-discovery" on both sides.
01-18-2012 06:22 AM
I've enabled "ip tcp path-mtu-discovery" and repeated test.
Receiver is cisco 2821, transmitter is cisco 3825.
Total CPU value was always below 15% on both devices.
Again it was very slow result ~200Kbit/s....
01-18-2012 06:26 AM
try to repeat the test with a tool "iperf" on one of servers, if it's possible.
But cisco 2821 can process in CPU only about 6Mbit/s. Have you checked "sh proc cpu history"? did you see any peaks there?
Upd. try to use ttcp with default parameters first.
01-18-2012 10:31 AM
01-18-2012 12:22 PM
yes, sure in CEFswitching on the forwarding path, but TTCP doesn't use CEF, it's a CPU based process which generate packet stream, with CEF it has nothing to do.
01-22-2012 11:30 PM
You're right, for transit traffic there is no problem. It must have been CPU/control-plane.
Thanx
01-23-2012 02:26 AM
Notwithstanding, packet sourced or destined for the CPU take a path thar is neither "process switched", or CEF. One cannot assume what is the performance for these packets.
That is also the reason why performance measurements should be done with external tools, not on the router.
01-23-2012 03:01 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Paolo Bevilacqua wrote:
Notwithstanding, packet sourced or destined for the CPU take a path thar is neither "process switched", or CEF. One cannot assume what is the performance for these packets.
That is also the reason why performance measurements should be done with external tools, not on the router.
Just to extend Paolo's point, Cisco routers and switches are optimized for their primary purpose. Anything that uses ancillary or host like functions is a performance crapshoot.
01-19-2017 05:32 AM
To again further expand on this issue..: I did some testing with the embedded FTP client in a Cisco 1921 router. At about 15 - 20 Mbits/sec the cpu was fully loaded and that was also the limit of the ftp transfer.
Both the line and ftp server capacity was *much* higher.
Edit:
I tested with a "copy ftp null:", so flash writing was not a bottleneck. As far as i can see, it's purely the router's CPU that's limiting the ftp speed.
01-19-2017 05:32 AM
If you're using the FTP client, and copying to/from the router, bandwidth will be restricted both by the time is takes to read/write from the router's flash and the router is not optimized for being a FTP host.
01-18-2012 12:48 PM
Hi,
200kB/s means 1,6Mb/s in fact.
I believe another increasing of the rcvwndsize might bring you a little better throughput.
But possibly there is still some limit for a single TCP session due to the RTD?
What is the Ping time between those two routers?
Maybe running multiple TTCP sessions (different ports) at the same time could load the line more?
HTH,
Milan
01-18-2012 01:39 PM
just to info, on a c7200 NPE-G1 I could reach with TTCP about 30-40 mbits/s but CPU was 100%
multiple ttcp's could be really helpful if CPU load doesn't reach 100%
01-18-2012 04:16 PM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Is there any tool on router to test performance ? (extended ping is not enough for >10Mbit/s links)
I use a freebie, pcattcp - use the UDP mode - set for continuous - set desired xmit rate.
I've tried to use ttcp, but it does not allow to set TOS and i can not test my QOS policies.
Set an inbound service policy to mark different test flows based on an ACL - for example, I've used different destination ports with the prior mentioned tool.
Why ttcp has so poor performance ?
As other poster mentioned, could be receiver's TCP isn't large enough for BDP. Other issues include insufficient time allowed for TCP to ramp up, any packets drops, etc.
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: