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

[Ed Criscuolo]

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.

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).  Would that be a better way to limit the amount of
data output at once?


@(^.^)@  Ed