[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Flowgraph running in "fits and starts"
From: |
Tom Rondeau |
Subject: |
Re: [Discuss-gnuradio] Flowgraph running in "fits and starts" |
Date: |
Mon, 6 Sep 2010 17:03:00 -0400 |
On Sat, Sep 4, 2010 at 8:47 PM, Eric Blossom <address@hidden> wrote:
> On Sat, Sep 04, 2010 at 08:22:38PM -0400, Marcus D. Leech wrote:
>> On 09/04/2010 08:08 PM, Tom Rondeau wrote:
>> > On Sat, Sep 4, 2010 at 12:19 AM, Marcus D. Leech <address@hidden> wrote
>> >
>> > Like Eric said, remove the throttle or at least change the rate and
>> > that should clean things up.
>> >
>> > Tom
>> >
>> >
>> I also noted in the reply to Eric that I observe the same behaviour with
>> an external source that is producing 4800 symbols/second--so
>> it's not the throttle *per se*, but rather the way that work "chunks"
>> get scheduled in Gnu Radio. With a "fast" source, you dont find yourself
>> in a situation where there aren't enough "chunks" to keep things busy.
>>
>> But a very reasonable example would be something like a cross-band
>> digital repeater application, where bits/symbols would be arriving
>> at the "channel rate", and need to leave the Tx in something at least
>> approaching real time--you certainly need to have a bit of
>> elastic buffering to compensate for clock-skew between the two sides,
>> but several-tens-of-seconds of latency isn't likely to be very
>> useful in the real world.
>>
>> Note that I'm not criticizing anybody or anything. I'm making
>> observations, and I *do* understand *why* it is the way it is.
>> My little test flow-graph failed the "least astonishment test", which
>> is why I felt I needed to comment.
>>
>> Would it be reasonable to open a discussion about this class of
>> flow-graph? I think they can be characterized as flow-graphs with
>> a low symbol rate, and high interpolation (which I think is where the
>> buffer-multiplier effect may be coming into play). In such flow-graphs,
>> would it be reasonable to be able to "tweak" the scheduler to deal
>> with this type of situation? I have little insight into how the scheduler
>> works in detail, but I think I understand the "fits and starts" that I
>> was observing.
>>
>> So, is this a reasonable discussion topic? Are other folks working on
>> "stuff" that will run into part of the performance diagram I ran
>> into yesterday? Or is everyone else working on high-event-rate type
>> signal chains?
>
> Marcus,
>
> This is certainly a reasonable discussion topic.
> I suggest before wading in that you first enable the scheduler logging
> that I mentioned in a prior post and take a look at that.
>
> Feel free to send me the logs too.
>
> What we're looking for is which block is forcing the large chunk size.
> If you were reading from a file using for example gr.file_source, it
> won't return until until it's completely filled up the downstream
> buffer given to it. That's just how it's written.
>
> A trivial change would be to have it loop until it it read
> min(N_USER_SPECIFIED_ITEMS, noutput_items) items.
>
> Eric
Marcus,
Indeed, this could be something we want to talk more about. Kind of on
the periphery of my vision, I can see a handful of applications where
the large chunking issue could be a problem. If we can define enough
need, then we can talk more about finding the right way about it.
Eric's suggestion is a good start. Tell it how many items you want and
then run the loop based off that number or the noutput_items,
whichever is smaller. If this works well for you, we might want to
find a way of integrating that concept as part of the
scheduler/basic_block.
Well, like I said, we can think this through more clearly if you come
up with positive results with that hack.
Tom