# Uhd\_rx\_cfile: getting constant O-overflows using the USRP B200 with debian

**URL:** <https://www.ruby-forum.com/t/uhd-rx-cfile-getting-constant-o-overflows-using-the-usrp-b200-with-debian/239910>\
**Category:** GNU Radio\
**Created:** [March 19, 2014, 1:44pm UTC](https://www.ruby-forum.com/t/uhd-rx-cfile-getting-constant-o-overflows-using-the-usrp-b200-with-debian/239910 "2014-03-19T13:44:33Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\
**Post date:** [March 19, 2014, 1:44pm UTC](https://www.ruby-forum.com/t/uhd-rx-cfile-getting-constant-o-overflows-using-the-usrp-b200-with-debian/239910/1 "2014-03-19T13:44:33Z")

</div>

Hi developers,

I have a fresh gnu radio installed with pybombs for my usrp B200. It  
runs on a Lenovo X230 with debian testing x64.  
When I use uhd\_rx\_cfile i get constant “O”-overruns (output given  
below).

The uhd-benchmark runs without problems:  
sudo ./benchmark\_rate --duration 600 --rx\_rate 32000000  
So the USB3-Port isn’t the Problem. Storing in ram is also fine:  
sudo ./uhd\_rx\_cfile -f 2445000000 --samp-rate=30000000  
/tmp/test.cfile  
I use a Samsung Evo 840 1TB (newest firmware) and did the  
SSD-Optimizations ([SSDOptimization - Debian Wiki](https://wiki.debian.org/SSDOptimization)) while  
searching for the error. HDPerm-, DD- and copy-benchmarks give 500mb/s  
for the first seconds, later constant ~400mb/s writing speed.  
Debugging with “iotop” brings (output below) 90% io-call-workload for  
the benchmarks, but 0% for the uhd\_rx\_cfile which writes only with  
240mb/s. So everything should work as expected.  
Btw: I also get overruns (at a lower rate) when sampling with lower  
sample rate and try to change the nice number.

Have you got any idea how to find and fix the bottleneck?

##################################################

user@debian:~/tools/grc/target/bin$ sudo ./uhd\_rx\_cfile -f 2445000000  
–samp-rate=30000000 /test/test.cfile -v

linux; GNU C++ version 4.8.2; Boost\_105400; UHD\_003.007.000-1-ga8caec5f

– Operating over USB 3.  
– Initialize CODEC control…  
– Initialize Radio control…  
– Performing register loopback test… pass  
– Performing CODEC loopback test… pass  
– Asking for clock rate 32 MHz  
– Actually got clock rate 32 MHz  
– Performing timer loopback test… pass

UHD Warning:  
The hardware does not support the requested RX sample rate:  
Target sample rate: 30.000000 MSps  
Actual sample rate: 32.000000 MSps  
Using mid-point gain of 36.5 ( 0.0 - 73.0 )  
Motherboard: B200 (E6R04Z7B2)  
Daughterboard: B200 (RX2, A:A)  
Rx gain: 36.5  
Rx baseband frequency: 2.445G  
Rx DDC frequency: -596.046m  
Rx Sample Rate: 32M  
Receiving samples until Ctrl-C  
Writing 32-bit complex floats  
Output filename: /test/test.cfile  
OOOOOOOOOOOO

#########################################

iotop

TID PRIO USER DISK READ DISK WRITE SWAPIN IO\> COMMAND  
171 be/4 root 3.91 K/s 0.00 B/s 0.00 % 6.63 %  
[kworker/u16:3]  
2656 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.04 % X :0 -auth  
/var/run/lightdm~olisten tcp vt7 -novtswitch  
3502 be/4 root 0.00 B/s 236.78 M/s 0.00 % 0.00 % python2  
./uhd\_rx\_cfile -f 2~0000000 /test/test.cfile -v

########################################

messung@debian:~/tools/grc/target/bin$ sudo hdparm -tT /dev/sda

/dev/sda:  
Timing cached reads: 17832 MB in 2.00 seconds = 8921.71 MB/sec  
Timing buffered disk reads: 1526 MB in 3.00 seconds = 508.55 MB/sec

---

<div class="post-metadata">

**Author:** ![Ingmar\_Splitt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/ed655f/32.png) [@Ingmar\_Splitt](https://www.ruby-forum.com/u/Ingmar_Splitt)\
**Post date:** [March 19, 2014, 4:10pm UTC](https://www.ruby-forum.com/t/uhd-rx-cfile-getting-constant-o-overflows-using-the-usrp-b200-with-debian/239910/2 "2014-03-19T16:10:34Z")

</div>

Hello Ingmar,

Can you please repeat the experiment with lower sampling rates (say, 10  
Mhz)? Thanks.

best,  
aditya

On Wed, Mar 19, 2014 at 8:42 AM, Ingmar Splitt \<
