[Top][All Lists]
[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