Kacheong Poon wrote:
If the reader does not use poll at all and instead reads in a delay
loop, each read will contain less data because of the block thus
forcing it to do more read calls for the same amount of data.
I suspect that the above is not always true. While one can
definitely write such a delay loop with the exact timing
to make things behave badly, it may not happen often. For
example, netperf is such a simple program. I remember Adi
had done extensive testing using it and the current code
did not make the performance worse. If Adi is reading this,
he can confirm this with data. The performance comparison
is against a normal fused TCP which only blocks the sending
side when the receive buffer is full. I think Adi has done
such tests in single (single thread) and multiple processors
system.
The netperf & rvperf numbers can be found in the Yosemite
white paper (I sent the URL to it in my previous posting).
The rest of measurement data, I believe, can be found in
one (or more) of the bugs related to Yosemite -- I recall
we had some other data such as those representing the
performance of a Java-based server app handling (chat?)
sessions?
The other thing we chose to run against prior to the putback
was the socket test suite for correctness issue. Details
of this and other testing should be there in the C-Team
archive.
In reality, it is the fact that our customers are actually
writing very optimized code which suggested Adi to come up
with the current algorithm to further optimize the fusion
performance. The original fusion code only blocks when the
receive buffer is full.
And the paper I mentioned above has the performance comparison
data between the original and current fusion implementations.
Adi
_______________________________________________
networking-discuss mailing list
[email protected]
