Hi Carl,
A question from our group about the following client params you mentioned
in your email (included below):
--max-frame-size N (65535) the maximum frame size to request.
--bounds-multiplier N (2) bound size of write queue (as a
multiple of
the max frame size).
--tcp-nodelay Turn on tcp-nodelay
Could you further explain/clarify the behavior of "--bounds-multiplier".
We read over the code comments in
trunk/qpid/cpp/src/qpid/client/ConnectionSettings.h
What exactly is the "write queue?" Based on the code comments, does
bounds allow outgoing frames to be larger than maxFrameSize for the
connection?
/**
* The maximum frame size that the client will request for this
* connection.
*/
uint16_t maxFrameSize;
/**
* Allows the size of outgoing frames to be limited. The value
* should be a mutliple of the maximum buffer size in use (which
* is in turn set through the maxFrameSize setting above).
*/
uint bounds;
Thanks,
Greg
On Tue, 11 Nov 2008, Carl Trieloff wrote:
> "Our analysis leads us to believe that the IPoIB limitations
> seen in our tests are due to the high IPoIB stack overhead.
> We believe that applying modern communication protocols,
> like RDMA, would improve this performance. "
>
> from the report --- I can confirm this, as the IPoIB driver consumers
> considerable CPU, which RDMA OFED does not.
>
> also, if you want to measure latency, setting
> --max-frame-size
> --tcp-nodely
> --bounds-multiplier
>
> on the client will greatly affect latency
> Carl.
>
>
>
