Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

OC-3 Problem

We have a point-to-point OC-3 that we brought up using 2x 7204VXR routers. The interfaces are ATM (which I have little experience with). The link is running perfectly clean, no errors, drops etc and we're seeing 12ms average round trip when pinging between the Headquarter and the DR site. The problem is when people try to copy file across that link they're only getting 22.8Mbps throughput at best. Is there any configuration in ATM that would prevent the whole pipe to be utilized? One router is providing clocking and I specified 155000. When I do a show int ATM 1/0 it also show bandwidth 155000.

What could be the problem?

Thanks for any input.

  • WAN Routing and Switching
3 REPLIES
New Member

Re: OC-3 Problem

hello johnson,

from my personal experience, when tring to utilize high bandwidth links,

the bottleneck in not the network but the endstations themself,

please observe the following points:

1. check that the end stataions not busy doing other tasks then the file transfer.

2. in order to fully utilize OC3 on the WAN, the endstations should be connected at 1G at the LAN.

check that there are no other bottlenecks between the endstations and the wan.

(if you want to utilize 100M on the WAN, so 100M NIC is enough - but make it full duplex)

3. it can be the fact that your are working with a "real" file transfer protocol,

those protocols have bottlenecks, for example:

- they are utilizing slow hard disk access.

- FTP for example have 4096 byte buffer size.

- TFTP have insufficiant flow control mechanisms.

- TCP window size can reach its limit.

those are just examples, have more protocols that each have its own drawbacks.

depand on which protocol you use, you should check its potential bottlenecks. OR, the better way,

you can use test tools that will workaround those problems,

those test tools are kind of traffic generators, my faivorate is Chariot of NetIQ,

it is software based and it simulates the real transport protocols.

you can use a hardware traffic generator, but be carefull with that if you are doing tests on a live network.

if you don't have such equipment you can run the test from few endstaions in paralel.

if you will make long enough test and run in at the same time, you might have resolts that will satisfy you.

I hope I gave you some ideas about what should you do, if you didn't solve the problem,

give me more details and we will see if we can work this out.

Galit.

Green

Re: OC-3 Problem

Chances are you're seeing a limitation in the Segmentation-and-Reassembly (SAR) process in your routers.

SAR is the process that chops the frames into cells at the transmit end, then re-assembles them at the receive end.

Back in the LANE/ATM-at-the-Core days, about the best SAR we ever measured (through a single system) in the Lab was ~50Mbps (using Fore Systems, Cisco, Bay Networks/Nortel, Xylan (now Alcatel) and IBM).

SAR is a fairly intensive task. To fill the OC3, you may want to add another layer of router(s) such that you have a layer that handles the several Ethernet segments-to-ATM and they feed the OC3-connected router(s) native ATM. That system aggregate the streams to fill the pipe.

This way you distribute the SAR function and relieve the processing load on the OC3 gateway system(s).

To test the system, check out a free application called Qcheck. It runs on a PC endpoint (one at each end) and operates from RAM (to rule out disk and other I/O systems). Qcheck will give you pretty good stats for throughput, latency, and packet drop for TCP and UDP traffic streams.

I believe you can still get it from http://www.ixia.com.

Good Luck

Scott

New Member

Re: OC-3 Problem

Thanks for the suggestions. We have ran the Qcheck program and here are the findings. We're still puzzled by what it could be:

Response time:

Settings

From (Endpoint 1) z1103

To (Endpoint 2) phxns01

Protocol TCP

Start Time 10/24/2005 10:46:00 AM

Stop Time 10/24/2005 10:46:01 AM

Iterations 10

Data Size 100 bytes

Response Time Results

Minimum 13 ms

Average 13 ms

Maximum 13 ms

Endpoint Details

Endpoint 1 Endpoint 2

IP Address z1103 phxns01

Endpoint Version 6.10 Build 068 (Retail) 6.10 Build 068 (Retail (Web-Based))

Operating System Windows XP (32-bit) 5.1 Build 2600 Service Pack 2 Windows Server 2003 5.2 Build 3790

Memory 2095196 (KB) 1047948 (KB)

Throughput:

Settings

From (Endpoint 1) z1103

To (Endpoint 2) phxns01

Protocol TCP

Start Time 10/24/2005 10:46:47 AM

Stop Time 10/24/2005 10:46:48 AM

Data Size 1000 kBytes

Throughput Results

Throughput 9.379 Mbps

Endpoint Details

Endpoint 1 Endpoint 2

IP Address z1103 phxns01

Endpoint Version 6.10 Build 068 (Retail) 6.10 Build 068 (Retail (Web-Based))

Operating System Windows XP (32-bit) 5.1 Build 2600 Service Pack 2 Windows Server 2003 5.2 Build 3790

Memory 2095196 (KB) 1047948 (KB)

UDP Streaming (this will only test 1Mbps, so is not very useful)

Settings

From (Endpoint 1) z1103

To (Endpoint 2) phxns01

Protocol UDP

Start Time 10/24/2005 10:47:53 AM

Stop Time 10/24/2005 10:48:06 AM

Send Data Rate 1000 kbps

Send Duration 10 seconds

Streaming Results

Lost Data 0 bytes (0.0%)

Actual Throughput 999.336 kbps

Endpoint Details

Endpoint 1 Endpoint 2

IP Address z1103 phxns01

Endpoint Version 6.10 Build 068 (Retail) 6.10 Build 068 (Retail (Web-Based))

Operating System Windows XP (32-bit) 5.1 Build 2600 Service Pack 2 Windows Server 2003 5.2 Build 3790

Memory 2095196 (KB) 1047948 (KB)

CPU Utilization 9% 0%

Anymore suggestions?

Thanks

101
Views
0
Helpful
3
Replies