Broken gr_fir_fff?

GNU Radio
#1

Sorry if I can’t provide any more debug info, I’m new and ignorant, but
I
updated from both the GnuRadio, UHD, and gr-air-mode repos today, and
now
I’m getting two programs with duplicate failure in gr_fir_fff. They
just
dump back to the shell after 2 seconds with no debug info.

Only thing I did in uhd_modes.py was add my ip addr to the uhd src, so I
don’t think it’s modifications I have made. It was working fine last
night,
but I did update from the repo today.

I made some modifications to usrp_flex_band.py to getting it working
with
the USRP2 and UHD However I made the same mods to usrp_flex.py and it
works
fine.

usrp_flex_band.py uses a 40 channel filter bank which I reduced to 4, in
an
attempt to debug, since it was causing a core dump, but I think that’s a
separate issue of thread resources (see the third excerpt below).

[email protected][/usr/local/src/gr-air-modes/src/python]$ ./uhd_modes.py -a
-g
30
linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400;
UHD_0001.20101201214203.8fc7521

Current recv sock buff size: 50000000 bytes
Setting gain to 30
Rate is 4000000

gr_fir_fff: using SSE
[email protected][/usr/local/src/gr-air-modes/src/python]$

[email protected][~/gnuradio_apps/pager]$ ./usrp_flex_band.py -g 30
linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400;
UHD_0001.20101201214203.8fc7521

Current recv sock buff size: 50000000 bytes

gr_fir_fff: using SSE
[email protected][~/gnuradio_apps/pager]$

[email protected][~/gnuradio_apps/pager]$ ./usrp_flex_band.py -g 30
linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400;
UHD_0001.20101201214203.8fc7521

Current recv sock buff size: 50000000 bytes

gr_fir_fff: using SSE
terminate called after throwing an instance of
'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injectorboost::thread_resource_error
’
what(): boost::thread_resource_error
Aborted (core dumped)
[email protected][~/gnuradio_apps/pager]$

–
View this message in context:
http://old.nabble.com/Broken-gr_fir_fff---tp30355695p30355695.html
Sent from the GnuRadio mailing list archive at Nabble.com.

#2

On Wed, Dec 01, 2010 at 08:05:51PM -0800, madengr wrote:

Sorry if I can’t provide any more debug info, I’m new and ignorant, but I
updated from both the GnuRadio, UHD, and gr-air-mode repos today, and now
I’m getting two programs with duplicate failure in gr_fir_fff. They just
dump back to the shell after 2 seconds with no debug info.

It’s unlikely that there’s a problem in gr_fir_fff.

What version of GNU Radio are you using?
What OS, distribution and version?
What hardware are you running it on?
How much memory does the machine have?
Is there anything interesting in /var/log/messages?

If there are 100’s of blocks in this graph, you may want to reduce the
default stack size allocated for each thread. (Even if not used, the
virtual address space is reserved.)

# Output from an x86_64 machine running Fedora 13

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63888
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 50
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

The default stack size is 10240k. You can probably reduce this to
4094k (or maybe 2048k) without a problem using:

$ ulimit -Ss 4096

Using -S sets the “soft limit”, which means you can set it back up
without being root:

$ ulimit -Ss 10240

Eric

#3

Can you pull the latest gnuradio next branch? I reverted some changes
with the tags until we can re-group. You may have run into an issue with
the work function implementation.

Let me know if that resolves the issue.
-Josh

#4

Yes, this solved my problems. Thanks.
Alex

#5

Eric B. wrote:

Is there anything interesting in /var/log/messages?
…

Eric

Using “next” branch of GNU Radio pulled on 12/3/10.
Pulled latest UHD source same day.
Using latest USRP2 firmware and bit file for UHD
Fedora 14, 32 bit
Dell M6500 Laptop with 4 GB RAM
Nothing from /var/log/messages or from dmesg

I’ve boiled it down to something more fundamental. I’m getting the same
behaviour with the simplest of flow graphs. I can’t seem to go faster
than 2 Msps into a single 265 point FFT sink (using GRC) without samples
halting after a few seconds. No over or under run messages, nothing.
The
GUI is responsive, but the data slow has halted. If I add on a filter I
can’t go past 1 Msps. With just a simple python script connecting a 10
Msps
USRP2 source into a null sink, it drops to the console in a few seconds
with
no info. I can’t sustain 20 Msps for more than 1 second.

[email protected][~/gnuradio_apps]$ ./bwtest.py
linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400;
UHD_0001.20101203153352.9d13960

Current recv sock buff size: 50000000 bytes
[email protected][~/gnuradio_apps]$

Laptop is connected to USRP2 via a 1000 Mb switch; lights show traffic
stops
and USRP LED C turns off. Straight connection to laptop makes no
difference.

benchmark_rx_rate is clean until 25 Msps, at which point it calculates
23
Msps sustained.

Firewall is disabled.

top shows python at 200% CPU when running, then drops off the process
list
when flow graph stops.

I did the “net.core.rmem_max=50000000” and “me - rtprio 50” tweaks.

Anyway, I could swear I was not having these problems a couple of weeks
ago.
I distinctly remember looking at the full 25 Msps bandwidth on an FFT
sink.
Of course that was with the stable GNU Radio release and non-UHD.

–
View this message in context:
http://old.nabble.com/Broken-gr_fir_fff---tp30355695p30366677.html
Sent from the GnuRadio mailing list archive at Nabble.com.

#6

Solved my problem too!
Thanks
Lou