discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] uhd_rx_cfile: getting constant O-overflows using


From: Aditya Dhananjay
Subject: Re: [Discuss-gnuradio] uhd_rx_cfile: getting constant O-overflows using the USRP B200 with debian
Date: Thu, 20 Mar 2014 09:28:48 -0400

Sorry, I do not.


On Thu, Mar 20, 2014 at 6:23 AM, Ingmar Splitt <address@hidden> wrote:

Hi Aditya,

 

Thanks for your reply. Today I got the chance to measure the lower samplerates and here are the results:

I measured the writingspeed on disk and the number of the “O”s for 1 minute runtime. Running X and iotop in the back has nearly no impact.

 

MHz   Mb/s    “O”-count

32      310         350

16      180         107

8        106           32

4          53             6

2          27             3

 

Do you have a hint for me for fixing this problem?

 

regards,

Ingmar

 

Von: Aditya Dhananjay [mailto:address@hidden]
Gesendet: Mittwoch, 19. März 2014 16:09


An: Ingmar Splitt
Cc: address@hidden
Betreff: Re: [Discuss-gnuradio] uhd_rx_cfile: getting constant O-overflows using the USRP B200 with debian

 

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 <address@hidden> wrote:

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 (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?

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

address@hidden:~/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


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

address@hidden:~/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

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]