On Sat, Sep 4, 2010 at 8:47 PM, Eric Blossom <e...@comsec.com> 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 <mle...@ripnet.com> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
