discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Scheduler Help/Question


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Scheduler Help/Question
Date: Thu, 8 Jan 2009 13:25:08 -0800
User-agent: Mutt/1.5.18 (2008-05-17)

On Thu, Jan 08, 2009 at 12:44:18PM -0800, Earle Frank wrote:
> 
> Eric Blossom wrote:
> > 
> > Let's say that block D never produces an output, but is consuming all
> > of it's input.  Can you see how this leads to a hang?
> > 
> 
> I can see that will cause the flow graph to hang. And I followed your
> explanation.
> I have added a "timeout" feature to block D, so that after a maximum of M
> samples, block D will output the appropriate enable signal.
> So now it is impossible for block D to consume all inputs and never produce
> an output.
> 
> Let me further describe my test:
> Let N=100, M=40.
> The expected enable signal out of block D is:
> 0 for n=0 to 49
> 1 for n=50 to 79
> 0 for n=80 to 89
> 1 for n=90 to 109
> 0 for n=110 to 199
> 
> Block A produce 100 samples to it's output buffer.
> Block B consumed all 100 samples of it's input and produced 100 samples to
> it's output buffer.
> Block C consumed all 100 samples of it's input and produced 100 samples to
> it's output buffer.
> 
> Block D consumed all 100 samples of it's input and produced the correct
> enable signal for n=0 to 89.
> The state inside block D is now 10, because it saw the beginning of an event
> from n=90 to 99. It is waiting for the event to end or for the state to
> reach M=40.
> 
> Block E consumed 90 input samples from the input buffer from B and from the
> input buffer from D to produce 30 outputs. These outputs are simply the
> values from block B at n=50 to 79.
> 
> 
> Eric Blossom wrote:
> > 
> > It goes like this.  E ends up BLKD_IN on it's second input, but
> > meanwhile the buffer on it's first input is full.  It's full because B
> > has been writing it as quickly as it can.  Once E's first input buffer
> > (== B's output buffer) is full.  B becomes output blocked.  It will
> > never run again because it's got nowhere to put it's output.
> > 
> 
> Shouldn't the output buffer be nearly empty for block B now? Block E has
> consumed 90 of the 100 samples from block B.
> Shouldn't block B be able to process another 90 samples or even 100 samples
> (assuming the output buffer is big enough)?
> 
> Why doesn't block A produce the next 100 samples to it's output buffer? And
> if it does, why doesn't block C consumed those 100 samples? And also, why
> doesn't block B consume at least 90 of those 100 samples??
> 
> 
> Thanks again for all the insight
> EF

Doesn't C do a set_output_multiple(N(==100))?  If so, and there's only 90
samples available it won't run.

You're on your own from here.  

This is K7GNU, clear.
Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]