The 72% is taking in consideration SONET & ATM overhead.
According to my calculations the theoretical rate should be 134.513 Mbps
available at application level on a OC-3 link.
If you consider additional bandwidth calculations ( about 8% less throughput
due to TCP Slow Start Time on a 540 msec RTT link and using about 10 Mbyte
window size) you will have about 123.24 Mbps available.
When we ran tests from end-to-end without going to gateways ( i.e. going to
an ATM switch and ADTECH channel emulator) we were close to 100% throughput.
However when using 2 gateways (2 sun ultra-2 machines doing ip_forwarding)
we saw the throughput going down some 20-30%. Some times this is due to system
limitations (stream allocation failures on gateways).
If you have more insigths on setting some optimal parameters on a sun box when
acting as a gateway I'll appreciate your feedback.
The window sizes are tuned to bandwidth*delay.
I guess that the important point in my e-mail was the rate of throughput
depreciation when increasing BER and, by contrary, a slow depreciation on SkyX.
In theory, one should be able to compute the exact time that is neccesary for
TCP to fill again the pipe after loss(es) and that is driving down the
throughput.
It is also true that ACTS provides an almost error-free link which means that
TCP behaves very well over this satellite link.
Another point is that this nearly 100% of theretical value for TCP throughput
over satellite ( no errors) requires sending a large amount of data (1 GB) and
setting the window sizes to Bd*delay product of the link.
I am aware of TCP automatic tuning efforts at LERC but one regular end-host
without knowledge of setting the TCP param. is going to see a small throughout
over a LFN. By contrary, SkyX takes over the responsability of optimizing
the transfer and makes the satellite link transparent to the end-user.
I don't know exactly how a Web-based type transactions (file transfers some of
them really small, internet browsing) is going to look over such a link.
Can the application (Netscape for example) set window sizes on a path over
satellite ? This is one direction of our future tests.
Marian Stagarescu
Thanks,
Marian Stagarescu
> X-Info: IDE / NASA Lewis Research Center
> X-Sender: [email protected]
> Date: Mon, 21 Dec 1998 07:18:38 -0500
> To: Marian Stagarescu <[email protected]>,
[email protected], [email protected]
> From: William D Ivancic <[email protected]>
> Subject: Re: TCP over IP over PPP (over Satellite)
> Cc: [email protected]
> Mime-Version: 1.0
>
>
> At 05:30 PM 12/18/98 -0500, Marian Stagarescu wrote:
> >...The TCP throughput w/ large windows and SACK over long-fat pipes
> (RTT=540 msec,
> >OC-3 links) is good (72% of theoretical rate) at low BER (none or 1E-10)
> >but it degrades heavily when BER is bellow
> >1E-7 (only 4% of theoretical rate for BER=1E-7).
> >
> >
>
> Why do you only get 72% of theoretical results for error-free links? Are
> you considering SONET and ATM overhead? Theory should be approximately
> 134-134.5 Mbps depending on the amount of extensions used. Do you have the
> advertised window set to theory or are you letting the data overrun the
> available link? At LeRC over ACTS and using the Adtech for delay/error we
> can get near theory minus a few percent due to the inability of the CPU and
> drivers to match theory. This is when the system is perfectly tuned.
>
>
> *********************************************
> William D. Ivancic
> NASA Lewis Research Center
> 21000 Brookpark Rd. MS 54-8
> Cleveland, Ohio 44135
> USA
> Phone: 1 216 433 3494
> FAX: 1 216 433 8705
> Email: [email protected]
> [email protected]
> *********************************************
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:52 EST