I am confused. I read the paper and I don't see the comparison that you
mentioned between the current and original fusion implementations. Is
the current what the graphs call "Yosemite"? If so, surely the
difference between Yosemite and the original fusion wasn't just the
implementation of the data block blocking was it?
Also, I am confused by the explanation of the performance improvement
from blocking by reducing the amount of data required to be processed
by a single copyout operation. Surely copyout has linear performance
characteristics or am I wrong?
Adi Masputra wrote:
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]
--
blu
"The genius of you Americans is that you never make clear-cut stupid
moves, only complicated stupid moves which make us wonder at the
possibility that there may be something to them which we are missing."
- Gamal Abdel Nasser
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
_______________________________________________
networking-discuss mailing list
[email protected]
