Unnecessary Frame Fragmentation using beepcore-c -- More Info

The initial diagnosis of this problem seems to be wrong.  We had thought
that the receiver did not have time to digest frames fast enough to keep
its window open, and the sender was trying to squeeze a partial frame
through as soon as any space opened up.

I implemented William Mills' suggestion, which was to have the sending
profile verify that enough window space is available in the (receiving)  
peer before sending.  However, it turns out that generally there is plenty
of window space but fragmentation occurs anyway!  And in the rare case
when the receive window is too full for a full frame, waiting until it
isn't so full still doesn't prevent fragmentation.

I am not quite sure what it means, but in further tests I found that
increasing the window size to 64K results in a bit of fragmentation only
for a few frames every 64K of message.  It seems as though having
previously sent smaller frames in a previous message has fragmented some
buffer space somewhere, and it is never getting consolidated.  So I would
now guess that this is an actual bug in the vicinity of CBEEP.c, and not
merely a tuning issue.  I verified that the receiver frees each frame with 
bpc_frame_destroy() after it reads it.

DCN

On Wed, 17 Sep 2003, David C Niemi wrote:
> As I started this whole discussion, I'll try to summarize it:
> 
> I have an application sending potentially large messages over a small
> number of channels (at the moment just one).  The large messages are sent
> rapidly (not waiting for per-frame acks) in max frame size (4K) chunks,
> which tends to fill up the peer application's receive window.  At that
> point the low-level (CBEEP.c) code tries to send whatever will fit into
> the peer's receive window, which is usually a tiny fragment of one of the
> 4K frames.  Each time the receiver reads a small frame fragment, it frees
> up a small part of its receive window, and another small frame is sent to
> make use of the new space.  Thus the system settles into a pattern of
> sending fragments for the entire large message, resulting in far more
> frames sent and read by the receiver, hurting performance.
> 
> The proposed solution is to let the sending application detect the peer's
> current receive window size, and to potentially hold off on sending the 4K
> frames until at least that much space is available, based on
> application-level logic.  I expect that a very small amount of delay by
> the sender will permit getting into a pattern of full-sized frames and
> thus result in better performance.  William Mills is looking into a clean 
> way to expose the peer's window size at the application level.
> 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
> 
> 

-- 
-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf