Without getting into the other aspects of your blog, the initial test is flawed from ignoring packet size, overheads, Ethernet packet spacing, half or full duplex on the Ethernet segment, distance latency, router latency, and the functional sequence of a TCP/IP transmission. It also ignores the performance of your end nodes.

What your test shows is the effective throughput of an FTP session between the two devices over the private T1 communications link.

To infer the performance impact of the communications link on the total performance using the suggested test, first do the file transfer with both machines (or a local machine configured in hardware and software the same as the remote machine) on a common Ethernet segment. This becomes the baseline time for the FTP session. The performance cost of packet size, overheads, Ethernet packet spacing, half or full duplex on the segment, and the functional sequence of a TCP/IP transmission, plus the performance impact of each end device, will be reflected in the baseline time.

Now run the test as suggested by Michael. The additional time is the performance impact of distance and router latency and bandwidth, plus communications errors (if any).

To further refine the result using only the test suggested, use a local 3 segment setup. Segment 1 (device sending the file), router, segment 2, router, segment 3 (device receiving the file) for the baseline. This setup will isolate the router latency so that when Michael's suggested test is performed, bandwidth and distance latency is approximately shown when comparing results to the baseline.

Be sure to use IP addressing rather than a named device when running the tests. If named devices are used, the initial test will include the associated DNS sequence, but subsequent tests may use locally cached host IP addressing.

Testing done while other nodes are active may result in inconsistent results.

Private Reply to Ken Hilving (new win)