Jack,
Are you able to make your tcpdump traces available as well as
the parameters used for testing as well as the length (bytes)
of the files you were using for ftp tests?
I'm confident that the mechanisms are OK (during our testing,
we've exceeded 30Mb/s over similar channels using UNIX boxes - w/o
SACK) but the loss patterns might be biting you (I'm guessing
that segments are being dropped in interesting clumps at the
receiver, perhaps this includes outgoing ACKs)...
If you can make the traces and other data available, I'd be
happy to help in examining them - otherwise I anxiously await
the final diagnosis :o)
Best Regards,
Eric
On Thu, 3 Sep 1998, Jack Stiekema wrote:
> Dear satellite friends,
>
> Did anyone of you ever got it working?
> I mean 3-30 mbit/s with 500ms delay and all rfc1332, 2001, 2018 options
> enabled.
>
> It looks like
> window scale, slowstart, congestion avoidance, fast retransmit, fast
> recovery, sack with/without timestamp,
> are conflicting by design or by implementation (i hope the last one) in our
> tests.
>
> We use Linux 2.1.117 and NT4-sp1 servers. Clients areNT4 and Windows95
> (standard, winsock2 and OnNet stack) machines for testing.
> We only see unreliable unstable throughput, and even falling back to
> congestion windows of 4k for minutes after a burst of a few seconds
> 3mbits/s.
> Througput is .3-3mbit/s using FTP protocol on a 500ms 10mbit link, and
> that's after tuning for day's all stack parameters (not for performance but
> for stability).
> As long as throughput is below 500kbit/s it looks ok but above that number
> real fun starts as machines (most of the time the client) are losing packets
>
> On this moment we are reading megabytes of tracing and counting the ack's so
> we'l let you know.
>
>
> Kind Regards,
> Jack Stiekema
>
> Philips Digital Video Systems, DTS
> Phone +31 6 22240066
>
>
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:46 EST