Re: [Discuss-gnuradio] forecast method for HDLC transmit block

[Eric Blossom]

On Thu, Oct 23, 2008 at 05:52:18PM -0400, Ed Criscuolo wrote:
> Eric Blossom wrote:
>> On Thu, Oct 23, 2008 at 04:56:04PM -0400, Ed Criscuolo wrote:
> >
>>> At this point, I think I'll embed all the packet reading AND
>>> hdlc processing into a single source block with no flow
>>> inputs.  This way the block can check for packets on the TUN
>>> device, read them, bitstuff and hdlc frame them, and put them
>>> into an internal ring buffer. Then it would return as many bits
>>> as requested, or flags if the ring buffer was empty.
>>
>> OK.  The only problem that I can see with this is that the scheduler
>> will run this block whenever there is space available in the
>> downstream buffer.  If your data rate is low (100's of b/s) we could
>> be adding a serious amount of latency to the system.  If this is a
>> deep space probe, no problem :-)  otherwise we may need to cookup some
>> way to limit the amount of buffer used between the blocks.  The
>> default is ~32KB.  If the data rate is relatively high, the 32KB of
>> buffering may not be an issue.
>>
>
> It's not deep space, just LEO (Low Earth Orbit), so speed-of-light
> latency is only on the order of 5 - 30 mS.
>
> This flow will be feeding the uplink, which runs at 9600 bits/sec.
> Not that low, but not very high either.

OK

> My initial plan, was to have the block output an unpacked stream
> of bits, one per byte.  Now, if I'm understanding you correctly,
> the scheduler will request as much as 32KB of output from this
> hdlc source block at one time.  At one bit/byte, and 9600 bits/sec,
> that amounts to just over 3 seconds worth of data.  If my ring
> buffer just happens to be empty, this means I'm going to insert
> 3 seconds worth of flags into the stream at once, even if I have
> a packet come along in the next millisecond.  This would cause
> me to fall behind, never to catch up.  The overall effect would
> be to reduce my effective data rate to something less than 9600.

> Seems like I should be checking for newly arrived packets after
> sending each flag, not just once per invocation of the work method.
> But this sounds like a lot of extra processing overhead.  Is it
> possible for a block to return less than the number of outputs
> requested? (I think the answer is yes for a block, no for a sync
> block).

You can return less.  In any event, the scheduler will call you again
if there's still room in the output buffer.

> Would that be a better way to limit the amount of data output at once?

I think the right answer is to come up with a way to limit the total
buffer space you see.

My suggestion is to not worry about it right now, get the rest of it
working, then we can fix this problem.  It shouldn't be a big deal.

(I just spent a couple of minutes looking at it.  It won't be hard to
limit the buffer space seen.  We just need to come up with a
reasonable API for it.)

Eric