FFT filter bug in GR3.7.4

Tag: v3.7.4git-50-ga8f73d85

This demonstrates a horrible bug I found in FFT filters–change the size
from “little” to “quite large”, and the scheduler goes running home to
momma:

thread[thread-per-block[1]: <block fft_filter_ccc (12)>]: Buffer too
small for min_noutput_items

I’ve attached a minimal GRC to show this.

On Tue, Apr 1, 2014 at 2:21 PM, Marcus D. Leech [email protected]
wrote:

I’ve attached a minimal GRC to show this.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

That’s actually not surprising. The buffer is established when the
top_block is started and will be based on the size of the FFT you need
to
run. Increasing the size of the filter will not increase the size of the
buffer. We’ll have to figure out how we want the solution to this to
look.
Might be we just refuse to increase the filter size during runtime so
you’ll have to lock/unlock the flowgraph. Will think more on this…

Tom

Tom
It’s counter to the experience with the regular dot-product FIR filters
in that you can re-size them at runtime and it’s just fine. It
certainly fails the
“least astonishment” test when you have a filter that’s configured
for “pass-through” (1+0j single tap) and then later ask it to do some
real
filtering.

But this bug has been around for a long time, as I was reminded. My
other code has “hacks” to get around this, and when I was re-structuring
for migration to GR3.7, it reared its unpleasant little head again.

Granted, my use case, in this case, is a bit weird–the filter can go
from “passthrough” to “farking massive” in one swell foop, when the user
turns on coherent dedispersion and suddenly that’s a rather-large
de-dispersion filter in the path.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

On Wed, Apr 2, 2014 at 6:08 PM, Marcus D. Leech [email protected]
wrote:

Agreed that it’s counter intuitive based on experiences with the
fir_filters. But that’s the difference between the overlap-and-save
algorithm that you need to process it a chunk at a time. Unless you want
us
to put in an internal buffer to store the data while it streams in
(which
should make Philip jump in here and scream about adding another memory
copy
operation).

Tom

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs