|
From: | Marcus Müller |
Subject: | Re: [Discuss-gnuradio] Discuss-gnuradio] How to specify maximum size of input buffers on blocks |
Date: | Mon, 29 Feb 2016 11:41:02 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 |
Hi Gonzalo, On 29.02.2016 04:58, Gonzalo Arcos
wrote:
Hm, while uniform usage is usually a good sign, that much average fill isn't good. You say "most" blocks; what's downstream of these high fill buffers? I don't really understand your question. The point is that the position of the write pointer might never pass the read pointer(s). The difference between the "most behind" read pointer and the write pointer is used to calculate noutput_items for the block's (general_)work call. In fact, your block is asked "to generate this much output, how much input would you need?" via its "forecast" method with exactly that difference. If your forecast says it needs more input than available, the number is halved, and "forecast" is called again, until forecast only demands as much input as available. At that point, general_work is called with noutput_items set to that number. umm... Buffer generation. Wait... Here it is: [1] and used here [2]. So, it defaults to 64KB buffers. That aligns nicely witht the observation that complex number buffers are typically 8192 items long (complex = float I + float Q = 32bit + 32bit = 8B; 8192 * 8 = 64K). If you have other restrictions (e.g. set_min_output_buffer, or item size not factor of page size (4KB)), you might get different sizes, though. Hm, that would be a nice feature, at least for experimentation (enlarging all the buffers might have pretty ugly effects on latency, so I wouldn't recommend doing it unless you know your sample rate * buffer_size/2 * blocks in critical path are significantly less than your tolerable latency). I don't think GNU Radio has that feature, though :) I'd say, in general, it's a good idea to manually enlarge the output buffers of the blocks upstream of CPU-intense blocks, but to keep granularity small in the rest of the flow graph. Feel free to experiment with [1]; you could remove the assignment of the #define constant to s_fixed_buffer_size and replace it with a call to const unsigned int s_fixed_buffer_size = prefs::singleton()->get_long("DEFAULT", "buffer_size", GR_FIXED_BUFFER_SIZE); and add a "buffer_size = X" to your .gnuradio/config.conf under the [default] clause¹. Best regards, Marcus ¹ um, yeah, that should make the staticness a bit conceptually questionable, which should lead to us renaming the variable, but... hey, experimentation! [1] https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/flat_flowgraph.cc#L41 [2] https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/flat_flowgraph.cc#L134
|
[Prev in Thread] | Current Thread | [Next in Thread] |