Re: Unnecessary Frame Fragmentation using beepcore-c?

I have not played with large data streams.  If the sender is faster than 
the recipient, I think we always run into this bounday, which does
not seem the best behavior.  From the API's point of view, it's doing it's
best to fill the available window on the other side, which I think is
the right thing.  

The API is providing a hard limit on the amount of buffering on the
receiving end. I guess the alternative is to do something at the profile level
which will run within the hard limit.  ACK's or some such within the profile
for example.

It might be interesting to make a mod to the API to allow something like
only sending SEQ's to open the window if they release more than a 
default frame size, or perhaps more than 10% of the window size.  
Doing this would be probably not too hard, but would be a change
down in the CBEEP.c stuff, and then it would have to be exposed
at the wrapper level too.

So I guess I don't really have an answer except that at the window
boundary the behavior of the API degrades, and that we know that.

-bill

On Mon, Sep 15, 2003 at 04:31:16PM -0400, David C Niemi wrote:
> 
> Do you have a suggestion as to a reasonable window size?  Perhaps 64K?  Or 
> truly huge?
> 
> The receiving app is pretty lightweight, but it DOES write the resulting 
> data to disk and thus will not be instantaneous, and may be a bit slower 
> than the sending application, which is merely READING from disk.  It seems 
> odd to me that the reaction to rapid sending is to fragment the frames 
> that are being sent, as that merely results in more frames.
> 
> DCN
> 
> On Mon, 15 Sep 2003, William J. Mills wrote:
> > David,
> > 
> > I did not find the default, but I think it's 4K.  Easy to tell
> > by looking at the SEQ frames in the startup though.
> > 
> > I'd say that 10K is too low for the window size for large
> > transfers.  I can't remembe what the default frame size is, but 
> > at 10K, if the frame is 1500 bytes you get <7 frames in flight.
> > 
> > If the recieving app is not consuming them as fast as they can be 
> > sent, you'll have this problem anyway.  I suspect however there might be an 
> > optimization somehow to keep the SEQ frames from causing  SEQ frame
> > sized payload packets...  but I am not sure.  
> > 
> > Setting it in the sending profile won't help.  Setting your own window size
> > controls what can be sent to you, nand should have no effect on your
> > outbound traffic directly.
> > 
> > -bill
> 
> -------------------------------------------------------
> -- 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