Hi Kai, The increased CPU usage is expected. It was done intentionally to make the UHD code more responsive to flow control messages in order to avoid underruns at higher sample rates. Appropriate yields were put in place to avoid starvation. What is not expected are the dropped packet (D) and receive timeout errors. Can you reproduce the errors by running just the RX side (./benchmark_rate --args="address=192.168.10.2" --rx_rate 20e6)?
Regards, Michael On Tue, Oct 24, 2017 at 5:40 AM, Kai-Uwe Storek via USRP-users < usrp-users@lists.ettus.com> wrote: > Is there something else I can in order to support the investigation of > the problem? Is it useful to open a new issue on github? > > 2017-10-20 19:23 GMT+02:00 Marcus D. Leech via USRP-users > <usrp-users@lists.ettus.com>: > > On 10/20/2017 04:20 AM, Kai-Uwe Storek via USRP-users wrote: > >> > >> Hey Marcus and Brent, > >> > >> thanks for suggestions. I'm not working in a VM. > >> > >> The benchmark tool underpins the behaviour: > >> > >> If I use the UHD version of the debian distribution, everything seems > >> normal: > > > > Interesting. This is definitely something to be followed up on. > > > > I took a closer look at my own FG in this context, and indeed one of the > > CPUs is completely pegged. > > > > > > > >> > >> ------------------------------------------ > >> /usr/lib/uhd/examples % ./benchmark_rate --args="address=192.168.10.2" > >> --rx_rate 20e6 --tx_rate 20e6 > >> linux; GNU C++ version 6.3.0 20170221; Boost_106200; > >> UHD_003.009.005-0-unknown > >> > >> > >> Creating the usrp device with: address=192.168.10.2... > >> -- X300 initialization sequence... > >> -- Determining maximum frame size... 1472 bytes. > >> -- Setup basic communication... > >> -- Loading values from EEPROM... > >> -- Setup RF frontend clocking... > >> -- Radio 1x clock:200 > >> -- Initialize Radio0 control... > >> -- Performing register loopback test... pass > >> -- Initialize Radio1 control... > >> -- Performing register loopback test... pass > >> Using Device: Single USRP: > >> Device: X-Series Device > >> Mboard 0: X300 > >> RX Channel: 0 > >> RX DSP: 0 > >> RX Dboard: A > >> RX Subdev: WBXv3 RX+GDB > >> RX Channel: 1 > >> RX DSP: 1 > >> RX Dboard: B > >> RX Subdev: WBXv3 RX+GDB > >> TX Channel: 0 > >> TX DSP: 0 > >> TX Dboard: A > >> TX Subdev: WBXv3 TX+GDB > >> TX Channel: 1 > >> TX DSP: 1 > >> TX Dboard: B > >> TX Subdev: WBXv3 TX+GDB > >> > >> Setting device timestamp to 0... > >> Testing receive rate 20.000000 Msps on 1 channels > >> Testing transmit rate 20.000000 Msps on 1 channels > >> UUU > >> Benchmark rate summary: > >> Num received samples: 200137060 > >> Num dropped samples: 0 > >> Num overflows detected: 0 > >> Num transmitted samples: 200114096 > >> Num sequence errors: 0 > >> Num underflows detected: 3 > >> Num late commands: 0 > >> Num timeouts: 0 > >> > >> > >> Done! > >> ------------------------------------------ > >> > >> > >> If I use the the maint version: > >> > >> ------------------------------------------ > >> ~/gr_prefixes/stable/lib/uhd/examples % ./benchmark_rate > >> --args="address=192.168.10.2" --rx_rate 20e6 --tx_rate 20e6 > >> linux; GNU C++ version 6.3.0 20170516; Boost_106200; > >> UHD_003.010.002.000-3-g122bfae1 > >> > >> > >> Creating the usrp device with: address=192.168.10.2... > >> -- X300 initialization sequence... > >> -- Determining maximum frame size... 1472 bytes. > >> -- Setup basic communication... > >> -- Loading values from EEPROM... > >> -- Setup RF frontend clocking... > >> -- Radio 1x clock:200 > >> -- Detecting internal GPSDO.... No GPSDO found > >> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1296.0MB/s) > >> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1299.4MB/s) > >> -- [RFNoC Radio] Performing register loopback test... pass > >> -- [RFNoC Radio] Performing register loopback test... pass > >> -- [RFNoC Radio] Performing register loopback test... pass > >> -- [RFNoC Radio] Performing register loopback test... pass > >> -- Performing timer loopback test... pass > >> -- Performing timer loopback test... pass > >> Using Device: Single USRP: > >> Device: X-Series Device > >> Mboard 0: X300 > >> RX Channel: 0 > >> RX DSP: 0 > >> RX Dboard: A > >> RX Subdev: WBXv3 RX+GDB > >> RX Channel: 1 > >> RX DSP: 0 > >> RX Dboard: B > >> RX Subdev: WBXv3 RX+GDB > >> TX Channel: 0 > >> TX DSP: 0 > >> TX Dboard: A > >> TX Subdev: WBXv3 TX+GDB > >> TX Channel: 1 > >> TX DSP: 0 > >> TX Dboard: B > >> TX Subdev: WBXv3 TX+GDB > >> > >> Setting device timestamp to 0... > >> Testing receive rate 20.000000 Msps on 1 channels > >> Testing transmit rate 20.000000 Msps on 1 channels > >> UUUUReceiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> UDOReceiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> > >> UHD Error: > >> x300 fw communication failure #1 > >> EnvironmentError: IOError: x300 fw poke32 - reply timed out > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> > >> UHD Error: > >> x300 fw communication failure #2 > >> EnvironmentError: IOError: x300 fw poke32 - reply timed out > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> Receiver error: ERROR_CODE_TIMEOUT, continuing... > >> > >> Benchmark rate summary: > >> Num received samples: 119843251 > >> Num dropped samples: 3194618 > >> Num overflows detected: 1 > >> Num transmitted samples: 175807996 > >> Num sequence errors: 0 > >> Num underflows detected: 5 > >> Num late commands: 0 > >> Num timeouts: 39 > >> > >> > >> Done! > >> ------------------------------------------ > >> > >> > >> Between these tests I did nothing then flashing the X300 with the > >> appropriate image and doing a power cycle. > >> > >> > >> > >> @Marcus: > >> If I use your flowgraph mit UHD 3.9.5, my CPU load is very modest. No > >> core higher than 15%. Executing the graph with UHD 3.10.2 causes again > >> 100% CPU load on a single core over the entire time. > >> > >> > >> > >> > >> > >> 2017-10-19 23:05 GMT+02:00 Marcus D. Leech via USRP-users > >> <usrp-users@lists.ettus.com>: > >>> > >>> On 10/19/2017 10:25 AM, Kai-Uwe Storek via USRP-users wrote: > >>>> > >>>> Hey, > >>>> > >>>> after experiencing some problems (time outs, etc) with the current UHD > >>>> develop version (master branch) I changed the UHD version to 3.10.2 > >>>> (maint branch, #122bfae). > >>>> > >>>> To do so, I just used the prefix recipe gnuradio-stable via pybombs. > >>>> > >>>> Now I'm not able to transmit even low bandwidth signals. My setup is > >>>> > >>>> - X300 via 1G ethernet > >>>> - gnuradio (maint branch) > >>>> - Debian with kernel 4.9. > >>>> > >>>> I used a simple flow graph with just a sine source directly connected > >>>> to the USRP sink block. Even for sample rates below 2MSamples/s one of > >>>> the cpu core of my Xeon E5-2630 v2 is 100% busy. > >>>> > >>>> Observing the cpu load with htop, I recognized that most of the cpu > >>>> load is red which indicates kernel space activities... > >>>> > >>>> After several seconds I finally got many "U"s in the console window. > >>>> > >>>> Some ideas how to isolate the problem? > >>>> Thanks in advance! > >>>> > >>>> Kai > >>>> > >>>> _______________________________________________ > >>>> USRP-users mailing list > >>>> USRP-users@lists.ettus.com > >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >>> > >>> I just constructed the attached flow-graph, and ran it on my ancient > Dell > >>> Latitude laptop: > >>> > >>> [mleech@lab ~]$ ./x300_test.py > >>> linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400; > >>> UHD_003.010.002.000-3-g122bfae1 > >>> > >>> -- X300 initialization sequence... > >>> -- Determining maximum frame size... 4320 bytes. > >>> -- Setup basic communication... > >>> -- Loading values from EEPROM... > >>> -- Setup RF frontend clocking... > >>> -- Radio 1x clock:200 > >>> -- Detecting internal GPSDO.... Found an internal GPSDO: LC_XO, > Firmware > >>> Rev > >>> 0.929a > >>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1290.6MB/s) > >>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1309.7MB/s) > >>> -- [RFNoC Radio] Performing register loopback test... pass > >>> -- [RFNoC Radio] Performing register loopback test... pass > >>> -- [RFNoC Radio] Performing register loopback test... pass > >>> -- [RFNoC Radio] Performing register loopback test... pass > >>> -- Performing timer loopback test... pass > >>> -- Performing timer loopback test... pass > >>> > >>> > >>> No underruns at all, and CPU was quite modest. > >>> > >>> > >>> Are you running within a VM? > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> USRP-users mailing list > >>> USRP-users@lists.ettus.com > >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >>> > >> > >> > > > > > > _______________________________________________ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > -- > Kai-Uwe Storek > > > > Privatsphäre auch bei eMails? eMail-Verschlüsselung leicht gemacht: > > Thunderbird: http://www.thunderbird-mail.de/wiki/Enigmail_OpenPGP > Outlook:https://code.google.com/p/outlook-privacy-plugin/ > Outlook (kostenpflichtig): http://www.gpg4o.de/en/ > product/productinfo-gpg4o.html > > Mein Schlüssel: http://goo.gl/QGVvsw > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
