beepcore-c-users Mailing List for C/C++ BEEP Core (Page 6)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Admittedly I have not doe this for a while, but we have examples,
but no way to have the makefiles construct a running example?

-bill

Marshall Rose wrote:
 > well, beepcore-c needs work. it shouldn't get into silly window
 > syndrome.

I'll agree with this. However, I'm not sure how one would get around 
this without having some sort of timer in the core, and still allow 
fragmentation of frames. I think within the constraints of the design 
(memory allocation strictly limited to the size of the windows 
allocated, minimal copying of data bytes, no asynchronicity in the core) 
  it works fairly well.

Certainly if you want to aglomerate frames, or have a timer wait a short 
time until there's enough room on the channel, etc, then you could 
improve it. That was kind of the intention of having beepcore keep track 
of the "biggest recent window" and the "current send window". The core 
could fragment file sections to fit whichever was appropriate, or wait a 
brief time for them to become the same if there was some desire to align 
things.

 > what happens now, where beepcore-c allocates 4K to each
 > channel is just plain STUPID.

Uh, no, not really. Firstly, the 4K window isn't what's causing the 
problem. Secondly, the 4K window's actually specified in RFC3081 3.1.1. 
If the caller of beepcore wants to bump up the receiving window size, 
it's easy to do, but it's under control of the caller, since that'll 
obviously affect how much memory it uses. I don't think we'd want to use 
your algorithm, for example, on a port to a Z80-based controller that 
only *has* 64K of memory.

Beepcore.c is behaving exactly how 3.1.2 of RFC3081 says it should. 
There's three possibilities listed there, and beepcore.c takes the 
first. The second requires support from the OS in terms of a timer, and 
we didn't want to  put any OS dependencies into that part of the system. 
What's under discussion right now is a way of making the third option 
possible; it had been planned, but never got implemented due to time 
constraints.

It doesn't matter how big the window is. If you're sending some small 
frames and some frames as big as the receiver's maximum window, then the 
big frames will get fragmented by beepcore.c if there's only a partial 
window available. That's true whether the window is 4K or 400K.

What would you suggest would be the proper solution to Silly Window 
Syndrome?

-- 
Darren New, San Diego CA USA (PST)
Don't take home left-over tripe.
   It'll just digest itself before
     you get around to eating it.

well, beepcore-c needs work. it shouldn't get into silly window
syndrome.

what beepcore-tcl does is this:

    - channel zero gets an explicit reservation of 4096
    - allow application to reserve, on a per-channel basis, how many
      octets from a logical pool of 65407 octets
    - allocate the remainder of the pool equally to those channels which
      don't have an explicit reservation
    - if the total reservations (excluding channel zero) do not equal
      65407, then all channels are scaled up or down equally

this allows "the right thing" to happen in most cases without any
application intervention. for example, in your application, your channel
would get about 59kB.

if an application needs to do something tricky, it can set relative or
absolute values.

what happens now, where beepcore-c allocates 4K to each channel is just
plain STUPID.

/mtr

On Tue, 16 Sep 2003, Marshall Rose wrote:
> could someone succinctly explain exactly what problem we're trying to
> solve. the beepcore-tcl implementation seems to work for several
> different apps without having this issue. perhaps there is some
> fundamental algorithm missing from beepcore-c that would obviate all of
> this...

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/ --
-------------------------------------------------------

could someone succinctly explain exactly what problem we're trying to
solve. the beepcore-tcl implementation seems to work for several
different apps without having this issue. perhaps there is some
fundamental algorithm missing from beepcore-c that would obviate all of
this...

/mtr

On Tue, 16 Sep 2003, Darren New wrote:
> Making it not fragment frames wouldn't be too hard. There's a routine
> that looks for the next frame to send, and you'd just have it say "Nope,
> not this one" if you have the flag set. I can't say I'm 100% sure what
> "NEVER_FRAGMENT" vs "AVOID_FRAGMENT" difference is.

I'm not sure either -- I was thinking that some applications might want to 
insist on their frame not being fragmented, while others might simply want 
to suggest as a hint that it would be better not to fragement it.  A moot 
point.

> I'd be leary of adding flags like this, tho, as they'd clearly make for 
> interop problems. Something a bit more robust in a wider range of cases 
> (like, not talking to BEEP.c) would be better. But then you'd have to 
> start dealing with timers and things like that, since I doubt you'd want 
> to completely stop sending if the receiver reduced its window size, for 
> example, and thus never got back to where you thought it should be.

I think I must agree.  Certainly introducing timers into BEEP.c is not 
something to take lightly.

I am quite happy with William's plan to let the sending application find
out the receiver's window size (as perceived by the low-level code on the
sender).  That way, whatever intelligence needed to tune the application
can be kept out of BEEP.c, at least if this all works as I anticipate.  
If it doesn't work as hoped (e.g. if window size tends to change between
the query and the send_chunk() operation), perhaps there could be a
version or flag of send_chunk() that returns an error if the receiving
window is too small to send the frame intact (leaving it up to the sending
application what to do about it).

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

David C Niemi wrote:
> Indeed, being able to determine what one's peer's window size is Right Now
> would do the trick.  An alternative would be to have more flexibility
> built into send_chunk(), being able to tell it NEVER_FRAGMENT vs
> AVOID_FRAGMENT vs SEND_IMMEDIATELY (the current behavior and presumably 
> the default).  Although I suppose BEEP.c wouldn't much enjoy implementing 
> the latter, as it doesn't want to block waiting for the window to open up 
> wider; perhaps instead it could return a EWOULDFRAGMENT error in that 
> case.

Making it not fragment frames wouldn't be too hard. There's a routine 
that looks for the next frame to send, and you'd just have it say "Nope, 
not this one" if you have the flag set. I can't say I'm 100% sure what 
"NEVER_FRAGMENT" vs "AVOID_FRAGMENT" difference is.

I'd be leary of adding flags like this, tho, as they'd clearly make for 
interop problems. Something a bit more robust in a wider range of cases 
(like, not talking to BEEP.c) would be better. But then you'd have to 
start dealing with timers and things like that, since I doubt you'd want 
to completely stop sending if the receiver reduced its window size, for 
example, and thus never got back to where you thought it should be.

-- 
Darren New, San Diego CA USA (PST)
Don't take home left-over tripe.
   It'll just digest itself before
     you get around to eating it.

I downloaded the source, and I think I have the build 
running on freebsd correctly.  I'll think about adding 
either a method to get what we think the peer window size 
is, or modifying bpc_set_window_size to take teh additional
special value -2...

-bill

On Tue, Sep 16, 2003 at 08:55:49PM -0400, David C Niemi wrote:
> On Tue, 16 Sep 2003, Darren New wrote:
> > William J. Mills wrote:
> > > bpc_set_window_size will return the recieve windows size, but
> > > not the peer's.  It returns the plocal size with an arg of -1
> > > and takes no action.  Perhaps we should add a -2 to get the remote
> > > size....
> > 
> > I'd suggest checking the documentation to see what I called it. I 
> > actually did think it through, and generally I think you want to be able 
> > to tell both how big the window is Right Now, and how big the window has 
> > been in recent times. I.e., you want to be able to get an idea of what 
> > the argument to the peer's bpc_set_window_size is, altho that's 
> > naturally harder than just looking at what we know right now.
> 
> Indeed, being able to determine what one's peer's window size is Right Now
> would do the trick.  An alternative would be to have more flexibility
> built into send_chunk(), being able to tell it NEVER_FRAGMENT vs
> AVOID_FRAGMENT vs SEND_IMMEDIATELY (the current behavior and presumably 
> the default).  Although I suppose BEEP.c wouldn't much enjoy implementing 
> the latter, as it doesn't want to block waiting for the window to open up 
> wider; perhaps instead it could return a EWOULDFRAGMENT error in that 
> case.
> 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
> 

On Tue, 16 Sep 2003, Darren New wrote:
> William J. Mills wrote:
> > bpc_set_window_size will return the recieve windows size, but
> > not the peer's.  It returns the plocal size with an arg of -1
> > and takes no action.  Perhaps we should add a -2 to get the remote
> > size....
> 
> I'd suggest checking the documentation to see what I called it. I 
> actually did think it through, and generally I think you want to be able 
> to tell both how big the window is Right Now, and how big the window has 
> been in recent times. I.e., you want to be able to get an idea of what 
> the argument to the peer's bpc_set_window_size is, altho that's 
> naturally harder than just looking at what we know right now.

Indeed, being able to determine what one's peer's window size is Right Now
would do the trick.  An alternative would be to have more flexibility
built into send_chunk(), being able to tell it NEVER_FRAGMENT vs
AVOID_FRAGMENT vs SEND_IMMEDIATELY (the current behavior and presumably 
the default).  Although I suppose BEEP.c wouldn't much enjoy implementing 
the latter, as it doesn't want to block waiting for the window to open up 
wider; perhaps instead it could return a EWOULDFRAGMENT error in that 
case.

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

Nevvermind....  freebsd supports poll.h

On Tue, Sep 16, 2003 at 04:53:55PM -0700, William J. Mills wrote:
> Heya,  anyone done a freebsd port yet?  It's close but not quite
> same as netbsd.
> 
> Hitting a problem with nfds_t at the moment, which I guess is part of
> poll.h....?
> 
> -bill
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

Heya,  anyone done a freebsd port yet?  It's close but not quite
same as netbsd.

Hitting a problem with nfds_t at the moment, which I guess is part of
poll.h....?

-bill

William J. Mills wrote:
> bpc_set_window_size will return the recieve windows size, but
> not the peer's.  It returns the plocal size with an arg of -1
> and takes no action.  Perhaps we should add a -2 to get the remote
> size....

I'd suggest checking the documentation to see what I called it. I 
actually did think it through, and generally I think you want to be able 
to tell both how big the window is Right Now, and how big the window has 
been in recent times. I.e., you want to be able to get an idea of what 
the argument to the peer's bpc_set_window_size is, altho that's 
naturally harder than just looking at what we know right now.

-- 
Darren New, San Diego CA USA (PST)
Don't take home left-over tripe.
   It'll just digest itself before
     you get around to eating it.

bpc_set_window_size will return the recieve windows size, but
not the peer's.  It returns the plocal size with an arg of -1
and takes no action.  Perhaps we should add a -2 to get the remote
size....

-bill

On Tue, Sep 16, 2003 at 10:29:39AM -0700, Darren New wrote:
> William J. Mills wrote:
> > If there is not at the moment, it could easily implemented.  Since CBEEP 
> > knows the open window size for the channel, it should be easy to implement
> > and accessor to get that per channel.  I don't remember such a function 
> > in the lib though.
> 
> I thought it was a return value from one of the other functions that had 
> to do with the window size, but I could be mistaken. As you say, it's 
> easy to tell. I know there's a *name* implemented for it, even if it 
> never got implemented properly.
> 
> -- 
> Darren New, San Diego CA USA (PST)
> Don't take home left-over tripe.
>    It'll just digest itself before
>      you get around to eating it.
> 
> 

William J. Mills wrote:
> If there is not at the moment, it could easily implemented.  Since CBEEP 
> knows the open window size for the channel, it should be easy to implement
> and accessor to get that per channel.  I don't remember such a function 
> in the lib though.

I thought it was a return value from one of the other functions that had 
to do with the window size, but I could be mistaken. As you say, it's 
easy to tell. I know there's a *name* implemented for it, even if it 
never got implemented properly.

-- 
Darren New, San Diego CA USA (PST)
Don't take home left-over tripe.
   It'll just digest itself before
     you get around to eating it.

If there is not at the moment, it could easily implemented.  Since CBEEP 
knows the open window size for the channel, it should be easy to implement
and accessor to get that per channel.  I don't remember such a function 
in the lib though.

-bill

> wait until the window is opened up to at least the size it wants to send.  
> This would especially make sense if it would help the session to settle
> into a pattern of 4K transfers.  Is there a straightforward and
> inexpensive way of detecting the peer's current window size on the fly?
> 

On Tue, 16 Sep 2003, Darren New wrote:
> Darren New wrote:
> > AFAIK, the frames are broken up at the lowest level, just before being 
> > sent, yes.
> 
> Oh, BTW, frames are *not* stuck together, which is where the problem 
> comes from.
> 
> So if you have a 12K window, try sending 4K frames. If the first gets 
> broken, it may recover easier. The other possibility is to set up with a 
> 4K window, and then if you send a 2096-byte short frame, send another 
> 2000 bytes from the file before bumping back up to 4K records. Either of 
> these might help without changing the library itself.

I had made what I thought was an optimization that might be making things
worse.  I am sending a CPIO file header as my way of encapsulating
multisegment messages, and for large files I was sending the header first
by itself so that I could send the file on 4K-aligned blocks.  I can
reasonably expand the window size quite a bit, but it will never be as big
as some files might be, and as I understand it a larger window size will
not solve this problem by itself.

I don't really want to introduce extra over-the-network handshaking or
unnecessary latency here, but if the sender can do something to detect
that BEEP.c would fragment the frame it wants to send, it could reasonably
wait until the window is opened up to at least the size it wants to send.  
This would especially make sense if it would help the session to settle
into a pattern of 4K transfers.  Is there a straightforward and
inexpensive way of detecting the peer's current window size on the fly?

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

Darren New wrote:
> AFAIK, the frames are broken up at the lowest level, just before being 
> sent, yes.

Oh, BTW, frames are *not* stuck together, which is where the problem 
comes from.

So if you have a 12K window, try sending 4K frames. If the first gets 
broken, it may recover easier. The other possibility is to set up with a 
4K window, and then if you send a 2096-byte short frame, send another 
2000 bytes from the file before bumping back up to 4K records. Either of 
these might help without changing the library itself.

-- 
Darren New, San Diego CA USA (PST)
Don't take home left-over tripe.
   It'll just digest itself before
     you get around to eating it.

David C Niemi wrote:
> Neither is the case.  From what William Mills is saying, this is a known
> flaw -- as frames pile up waiting to be read, the fragmentation results in
> yet more frames piling up because the 4K frames that were "sent" are
> broken up, perhaps at the BEEP.c level.

AFAIK, the frames are broken up at the lowest level, just before being 
sent, yes.

>  As you say, it would make sense
> that if frames are removed from the buffer 4K at a time, they'd free up 4K
> for another 4K frame.  But once a smaller frame is sent, only that much
> will be freed up when it is received, and it never gets quite back to
> full-sized frames again.  Perhaps if I carefully choose the window 
> size...but a multiple of 4096 bytes doesn't seem to do it.

Ah, OK. It becomes clear now. You *do* send *some* small frames. Are you 
getting acknowledgements of these frames? Perhaps after sending a small 
frame, you can either wait until a big frame comes back, or design the 
profile to open two channels and send big frames.

Or BEEP.c could be modified to wait until it has accumulated some amount 
of SEQ window available before starting on with the transmitting. I'm 
pretty sure there's a way to query what the receiver's window size 
currently is, also.  (And there was planned a way of querying the recent 
biggest window size, so you could guess what the receiver had set the 
buffer size to.)

>>Sure. Any time you have more than one channel, and the receiver is only 
>>reading a little at a time, say.
> 
> Ah, so when you have many channels receiving small messages via a single
> shared receive buffer, my idea would be rather bad.

Not so much a shared receive buffer, but different channels processing 
at different speeds. Think of something like "expidited data" or some 
such. If you had, for example, small control messages interspersed with 
data messages ("10% done!") you wouldn't want to block after queuing the 
progress message before sending the next frame.

Or if you have an IM client that supports file downloads, and you want 
the chats to not wait for the file to finish downloading before the chat 
messages show up. Or multiple file downloads going at the same time, in 
which case I'm pretty sure I remember designing BEEP.c to round-robin 
when you have all the window sizes the same.

 >  And I imagine the
> receiver has no idea whether it's about to receive a tiny fragment or a
> whole tiny message when it says it's got some small amount of space.

Generally, the receiver wouldn't know this, no.

> Would it make any sense to be able to have separate receive buffers for
> each channel, or is that contrary to the protocol or otherwise untenable?

Technically, there are different buffers, sure. The library sucks up as 
much memory as you set all your receive windows to. If you have three 
channels, each set to a 10K window, the library will happily suck up 30K 
of buffer space (plus overhead).

> I suppose it is also conceivable that I could speed up the receiver
> somewhat, but as its ultimate job is to write data any buffering I do
> there will eventually end up waiting for disk I/O.

The problem isn't with the speed of the receiver. It's that you read a 
small chunk, and that generates a SEQ right away, which the sender then 
uses to open the window, see things pending, and send them off. Having 
the sender wait for an acknowlegement after sending a short frame would 
help with this.

-- 
Darren New, San Diego CA USA (PST)
Don't take home left-over tripe.
   It'll just digest itself before
     you get around to eating it.

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/ --
> -------------------------------------------------------
> 

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/ --
-------------------------------------------------------

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

On Fri, Sep 12, 2003 at 04:17:38PM -0400, David C Niemi wrote:
> 
> Any idea what the default window size is, and what a good window size 
> would be in order to facilitate the sending of full 4K frames?
> 
> In the receiving profile, it appears to be defaulting to 4K.  Should it be 
> 4K plus some extra space for some structure that must be passed?
> 
> I've tried bpc_set_channel_window(pi->channel, 10000L) in the receiving
> profile, which seems to work, but it still fragments just as badly.
> 
> Perhaps I need to also set it in the sending profile?  Or perhaps Darren
> New is right that I am pushing the lower layers too hard and making them
> send partial frames -- in which case I'm not sure what to do.
> 
> I've already modified the application to deal with partial frames, so it 
> is really performance I am concerned about more than convenience.
> 
> DCN
> 
> On Fri, 12 Sep 2003, William J. Mills wrote:
> > bpc_set_channel_window() can be called within the context of a profile on 
> > it's channel object.
> > 
> > That's in bpc_wrapper.c in thew rapper directory.
> > 
> > -bill
> 
> -------------------------------------------------------
> -- David C. Niemi           Adeptech Systems, Inc.   --
> -- Reston, Virginia, USA    http://www.adeptech.com/ --
> -------------------------------------------------------
> 
> 

On Fri, 12 Sep 2003, William J. Mills wrote:
> bpc_set_channel_window() can be called within the context of a profile on 
> it's channel object.
> 
> That's in bpc_wrapper.c in thew rapper directory.

I have used bpc_set_channel_window() to bump up the window size on the
receiver to 10K, but with no obvious improvement.

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

Any idea what the default window size is, and what a good window size 
would be in order to facilitate the sending of full 4K frames?

In the receiving profile, it appears to be defaulting to 4K.  Should it be 
4K plus some extra space for some structure that must be passed?

I've tried bpc_set_channel_window(pi->channel, 10000L) in the receiving
profile, which seems to work, but it still fragments just as badly.

Perhaps I need to also set it in the sending profile?  Or perhaps Darren
New is right that I am pushing the lower layers too hard and making them
send partial frames -- in which case I'm not sure what to do.

I've already modified the application to deal with partial frames, so it 
is really performance I am concerned about more than convenience.

DCN

On Fri, 12 Sep 2003, William J. Mills wrote:
> bpc_set_channel_window() can be called within the context of a profile on 
> it's channel object.
> 
> That's in bpc_wrapper.c in thew rapper directory.
> 
> -bill

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

bpc_set_channel_window() can be called within the context of a profile on 
it's channel object.

That's in bpc_wrapper.c in thew rapper directory.

-bill

On Fri, Sep 12, 2003 at 12:46:57PM -0700, William J. Mills wrote:
> Looks like blu_local_window_set is the function that does what we need, but that's in CBEEP.h under the base directory.  Need to find where it's exposed at a higher level...
> 
> -bill
> 
> On Thu, Sep 11, 2003 at 10:28:32AM -0400, David C Niemi wrote:
> > 
> > Darren's suggestion about sending too fast and your suggestion about the
> > window size both sound promising.  The very first few frames were not
> > fragmented, but before long it began to fragment as I described, and I was
> > indeed feeding the frames in very rapidly.
> > 
> > So how does one adjust the window size, and what is a sensible amount to 
> > set it to?  This is currently running over loopback, where MTU is 16K.
> > 
> > Meanwhile I've modified my application to reassemble the tiny fragments as
> > needed, but I expect that avoiding the fragmentation in the first place
> > will substantially improve performance.
> > 
> > DCN
> > 
> > On Wed, 10 Sep 2003, William J. Mills wrote:
> > > This has to do with the frame size and window size.  The data payload
> > > will be reduced by the amount of the frame headers, which is the 
> > > missing info to make the payload sizes make more sense I think.
> > > 
> > > My suspicion is that the frame and window sizes are perhaps
> > > similar....  try cranking up the window size and see what that does.
> > > 
> > > -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
> > _______________________________________________
> > Beepcore-c-users mailing list
> > Bee...@li...
> > https://lists.sourceforge.net/lists/listinfo/beepcore-c-users
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

Looks like blu_local_window_set is the function that does what we need, but that's in CBEEP.h under the base directory.  Need to find where it's exposed at a higher level...

-bill

On Thu, Sep 11, 2003 at 10:28:32AM -0400, David C Niemi wrote:
> 
> Darren's suggestion about sending too fast and your suggestion about the
> window size both sound promising.  The very first few frames were not
> fragmented, but before long it began to fragment as I described, and I was
> indeed feeding the frames in very rapidly.
> 
> So how does one adjust the window size, and what is a sensible amount to 
> set it to?  This is currently running over loopback, where MTU is 16K.
> 
> Meanwhile I've modified my application to reassemble the tiny fragments as
> needed, but I expect that avoiding the fragmentation in the first place
> will substantially improve performance.
> 
> DCN
> 
> On Wed, 10 Sep 2003, William J. Mills wrote:
> > This has to do with the frame size and window size.  The data payload
> > will be reduced by the amount of the frame headers, which is the 
> > missing info to make the payload sizes make more sense I think.
> > 
> > My suspicion is that the frame and window sizes are perhaps
> > similar....  try cranking up the window size and see what that does.
> > 
> > -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
> _______________________________________________
> Beepcore-c-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-c-users

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (13)	Sep (2)	Oct (22)	Nov (6)	Dec (5)
2002	Jan (14)	Feb	Mar (10)	Apr (2)	May (2)	Jun	Jul (22)	Aug (41)	Sep (18)	Oct (7)	Nov (6)	Dec (17)
2003	Jan (10)	Feb (17)	Mar	Apr (8)	May	Jun	Jul (2)	Aug (1)	Sep (38)	Oct (17)	Nov (8)	Dec (5)
2004	Jan (27)	Feb (4)	Mar (20)	Apr (12)	May	Jun	Jul	Aug (1)	Sep (5)	Oct (1)	Nov	Dec
2005	Jan	Feb	Mar (4)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2006	Jan (7)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (6)

beepcore-c-users Mailing List for C/C++ BEEP Core (Page 6)

beepcore-c-users — Discussion list for developers using beepcore-c library