Asymmetric TCP/ATM throughputs between client and server

Edwin Law (e-law@cs.yorku.ca)
Fri, 27 Mar 1998 04:47:27 -0500 (EST)

Hi,
I wonder if anyone has encountered a similar problem before. I have
obtained different throughput readings when transferring data between a
client and a server from both directions. I am talking about a different
of about 50 times in magnitude. This happens when I use the TCP/IP over
ATM and the default ATM MTU of 9188 on two Sun's running Solaris. When I
set the ATM MTU to 65535, the problem goes away.

I suspect there is some kind of deadlock and time out ocurring. Some
papers discuss a throughput deadlock situation which could happen in
TCP/IP over ATM environments. I'm not sure if this is the case because it
cannot explain why it occurs in one direction only.

To help understanding the problem more, I measured the time taken for
each individual read or write call in both directions. 10 chunks of 8KB
data were sent in each case.

Client -> Server
----------------
(server read) (client write)
1 0.000867 0.000739
2 0.000634 0.000471
3 0.000759 0.000387
4 0.002860 0.001939
5 0.000863 0.000356
6 0.000697 0.003460
7 0.001868 0.000968
8 0.000612 0.000403
9 0.001159 0.002203
10 0.000922 0.000489
----------------
Total: 0.011424 second

Server -> Client
----------------
(server write) (client read)
1 0.000707 0.052361
2 0.000948 0.043168
3 0.000406 0.050055
4 0.092609 0.050401
5 0.000859 0.049735
6 0.099258 0.049865
7 0.000422 0.049974
8 0.099437 0.050011
9 0.000362 0.049966
10 0.099599 0.050677
----------------
Total: 0.496438 second

As far as I know, the throughput deadlock is a result of the presence of
the delay acknowledgement at 200ms time intervals, which does not seem to
relate to my case. I hope someone may know something about this.

Thanks in advance,
Edwin.