Re: Unnecessary Frame Fragmentation using beepcore-c?

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