Dear Marcus,
Thank you. I will explain my setup and system below
I am running Ubuntu 13.04, kernel: 3.8.0-35-generic in a VM.
I am using a pybombs-installed GR version v3.7.2.1-195-g19d111e2.
The description below is a small component of my overall system design; what
I’m seeking to do is include a multiple-producer, multiple-consumer queue into
the flow graph. The c++ code for this test program is here:
Source:
https://github.com/tjt7a/GR-Router/blob/master/apps/transparent.cc
The flow graph:
[WAVFILE SOURCE] - [THROTTLE] - several[FFT/IFFT]s - [THROUGHPUT] -
[OUTPUT QUEUE SINK] —|QUEUE|— [OUTPUT QUEUE SOURCE] - [FILE SINK]
It may seem unnecessary to include a QUEUE in the case about, but I am
benchmarking having a QUEUE vs. not using one.
Explaining the different blocks:
[FFT/IFFT] block is a hierarchical dummy load. It accepts a stream of
floats, vectorizes the stream, does a forward FFT, then a reverse FFT, and
de-vectorizes.
Source: https://github.com/tjt7a/GR-Router/blob/master/apps/fft_ifft.cc
[THROUGHPUT] block is a transparent block that returns the running
average throughput; it’s basically the compliment of the [THROTTLE BLOCK]
(existing gnu radio::blocks)
Source:
https://github.com/tjt7a/GR-Router/blob/master/lib/throughput_impl.cc
**This is where I’m getting the error message**
[OUTPUT QUEUE SINK] block accepts a stream of floats, packages them
into a series of 1024-float vectors, tacks on a message type, message index,
and message size, and pushes the address of these messages onto the lock free
queue.
Source:
https://github.com/tjt7a/GR-Router/blob/master/lib/queue_sink_impl.cc (I would
ignore the if(preserve) for now)
|QUEUE|: This is a boost::lockfree::queue. This queue supports multiple
producers and consumers. It dynamically grows in size. (unless I were to
constrain the size)
Source:
http://www.boost.org/doc/libs/1_53_0/doc/html/boost/lockfree/queue.html
[OUTPUT QUEUE SOURCE] block is basically the compliment of the [OUTPUT
QUEUE SINK] block. It pops message addresses off of the queue, reads headers,
and dumps the data on the output.
Source:
https://github.com/tjt7a/GR-Router/blob/master/lib/queue_source_impl.cc ( I
would ignore the if(preserve) and if(order) cases for now … I plan to use a
heap in the future for ordering)
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
On Mar 27, 2014, at 4:41 AM, Marcus Müller <[email protected]> wrote:
> Signed PGP part
> Hi Tommy,
>
> as this, I haven't seen it.
> However, this is really guessing - could you supply a little more
> information (Platform, GR version, OS version etc) and try to do a
> backtrace?
> Since you have problems with low-level and scheduler-related code (and
> if I remember correctly, not the first time), a little information on
> your application as whole and in detail how you use that block would
> obviously be of help ;)
>
> Greetings,
> Marcus
>
> On 27.03.2014 06:09, Tommy Tracy II wrote:
> > Dear Gnuradio Community,
> >
> > I ran my GNURADIO program and got the following error message:
> >
> > thread[thread-per-block[357]: <block queue_sink (4)>]:
> > std::bad_alloc
> >
> > This looks like a memory allocation problem with the scheduler. Has
> > anyone seen this before? What would cause this?
> >
> > Sincerely, Tommy James Tracy II Ph.D Student High Performance Low
> > Power Lab University of Virginia Phone: 913-775-2241
> >
> >
> >
> >
> > _______________________________________________ Discuss-gnuradio
> > mailing list [email protected]
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
