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
