On 05/18/10 12:53 PM, Ken Mandelberg wrote:
Well, I've learned a little bit more, but there is still a puzzle.
As it turns out, the issue of ttcp speed on Solaris was not related to whether
it was doing a read/write vs just doing writes on internally generated data.
The internally generated data was ascii, while the external data I was using
was a compressed binary. When I send a file with the same ascii data
externally, I get the same speed as when it is generated internally.
So I assume Clearwire is employing some data compression on the link to the
receiving node. This would explain it entirely, except for one thing.
I looked at the traces you provided. The difference between *rdwr*
and *wr* is that there are many more out of order segments and
retransmissions in *rdwr* traces. Note that even in the *wr* traces,
there are also a few out of order segments, just not enough to make
a huge impact. So it seems that the driver may be doing something
strange such that it sends certain type of data out of order. Because
of this, the TCP performance suffers. From TCP's perspective, the
actual data should not be relevant.
Linux gets about the same fast speed on both the text data, and the binary data.
Specifically:
Solaris: Text 972KB/sec, Binary 147K/sec
Linux: Text 1563KB/sec. Binary 1373K/sec
So the mystery is why the Binary speed is so degraded sending from Solaris.
So there may be a bug in the Solaris driver. I guess you need to
check with the driver vendor about this.
The Linux machine sits next to the Solaris machine on the same LAN. All the
transfers were to the Clearwire node within a few minutes of each other.
The new snoops are in the same directory mentioned above.
--
K. Poon.
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
