HSSI Bandwitdh Expectation

[ekahan.hess]

What would you expect if you take the following facts into consideration?

1. A E1 circuit is connected via a nortel router at either end. The

routers at each end plug in to nortel 450 switches.

2. A workstation in NY running NT maps a drive letter to a device in

London and at a command prompt copies a 10mb file. The copy takes 1min

22sec

3. The same workstation copies the same file to another local

Workstation in NY. That copy takes 4 seconds.

4. A file copy of the same file is also done from workstation in

London. Copy time is 2.2 seconds.

5. A DS3 circuit is brought up between NY and London with a CICO router

at either end. The routers at either end plug into the very same Nortel

switches as above.

6. What should the expectation be for the file copy from NY to London

be assuming it goes over the DS3?

[svermill]

I don't think this question can be answered from the information given. If you look purely at bandwidth, you'd reach these conclusions:

10 MBytes * 8 bits per byte = 80 Mbits to be transferred.

80 / 2.048 (E1) = 39 seconds

80 / 44.736 (T3) = ~2 seconds

Of course, that assumes no other traffic whatsoever is crossing the link (not a reasonable assumption) and that there is no propagation delay (obviously not the case).

One of the real issues is the file transfer process and perhaps some tcp limitations on high bandwidth*delay product pipes such as your DS-3 example. I don't know a lot about Windows, but if you are running that OS, it is my understanding that when you map a drive and transfer a file, it is done via some Microsoft proprietary process that rides directly above tcp.

If my assumptions so far are anywhere near correct....

First, you would need to capture the file transfer with a protocol analyzer and look at what kind of tcp window sizes are being offered. Then you need baseline what the average round-trip time (rtt) is. In this way you can determine what your max throughput will be from a tcp perspective.

The max throughput of a tcp session is dictated by window size and delay (rtt). The max value of window size is 64 kBytes (unless extended window size is supported). Often times, a Windows machine will offer a much smaller window than that!

max tcp throughput = window / rtt.

So even if your hosts are offering the full 64 kBytes…

65,535 / .2 sec (a guess) = 327,675 bytes/sec * 8 = 2,621,400 bits/sec

Not much better than your E1, eh? What kind of times are you seeing, just out of curiosity?

(also keep in mind that tcp slow-start and some other “features” will affect your actual transfer time

[steve.barlow]

This is how I was taught and if someone has something else I would like to hear it as well:)

Numbers rounded (eg. T1 = 1.544 but I do the math as 1.5.)

Latency or delay of putting a packet onto a line (serialization) can be measured by: [mtu*8]/link_speed_bps.

So to put a 1500byte packet on a T1 line (1.5Mbps) takes 7.8ms. To put a 1500byte packet on a E1 line (2Mbps) takes 6ms.

So, assuming a 1500byte packet, to transfer a 10Mbyte file would take about 6667 packets. This would take about 40000ms or 40sec. on a E1 line. This doesn't take into account PC delay or LAN delay, just on the E1 link assuming no other traffic or congestion.

To move that same file with the same mtu on a DS3 (45Mbps) about 1.8 seconds (all things being equal, no congestion etc).

So it should be about 22 times faster (40 seconds:1.8seconds).

You can change the MTU numbers to whatever your environment reflects, and factor in other delays as you see them happening (as they are happening- ideal time would be 40 seconds but you see 82).

Hope it helps

Steve