Hi Sumit, So it looks like you have multiple version of UHD installed:
john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$ sudo ./benchmark_tx.py -f 2.45G -S 10 linux; GNU C++ version 5.3.1 20151219; Boost_105800; UHD_003.009.002-0-unknown john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ sudo ./benchmark_rate --rx_rate 10e6 --duration 600 [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.15.0.git-1-gf83faf28 I would recommend to stick to a single UHD version and use the latest stable tagged released (currently 3.14.1.0) you will need to modify the pybombs recipe to use the correct git tag (v3.14.1.0). The 'master' branch can be unstable at times. Also, if you have a FPGA image of say 3.15.x.x flashed on the N210 and then revert back to using 3.9.2, and UHD does not catch the mismatch, it will likely cause flow control errors and unstable performance. The gr-digital/examples/narrowband/benchmark_tx.py example is also buggy, and is being removed from GR 3.8. Using the UHD benchmark_rate utility will test the hardware with a limited scope. Regards, Nate Temple On Wed, Jul 17, 2019 at 8:10 AM Sumit Kumar <cog...@gmail.com> wrote: > Sorry, here it is. > > Benchmark rate summary: > Num received samples: 5999986436 > Num dropped samples: 0 > Num overruns detected: 0 > Num transmitted samples: 0 > Num sequence errors (Tx): 0 > Num sequence errors (Rx): 0 > Num underruns detected: 0 > Num late commands: 0 > Num timeouts (Tx): 0 > Num timeouts (Rx): 0 > > > On Wed, Jul 17, 2019 at 5:08 PM Nate Temple <nate.tem...@ettus.com> wrote: > >> Hi Sumit, >> >> It will take 10 minutes for that run to complete. Does it produce a >> report at the end of the run? >> >> Regards, >> Nate Temple >> >> On Wed, Jul 17, 2019 at 8:06 AM Sumit Kumar <cog...@gmail.com> wrote: >> >>> Hi Nate, >>> No there are not. At the end of the last line, cursor keeps blinking, no >>> sequence errors. >>> >>> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ sudo >>> ./benchmark_rate --rx_rate 10e6 --duration 600 >>> >>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; >>> UHD_3.15.0.git-1-gf83faf28 >>> [00:00:00.000024] Creating the usrp device with: ... >>> [INFO] [USRP2] Opening a USRP2/N-Series device... >>> [INFO] [USRP2] Current recv frame size: 1472 bytes >>> [INFO] [USRP2] Current send frame size: 1472 bytes >>> Using Device: Single USRP: >>> Device: USRP2 / N-Series Device >>> Mboard 0: N200r4 >>> RX Channel: 0 >>> RX DSP: 0 >>> RX Dboard: A >>> RX Subdev: SBXv3 RX >>> TX Channel: 0 >>> TX DSP: 0 >>> TX Dboard: A >>> TX Subdev: SBXv3 TX >>> >>> [00:00:01.796895] Setting device timestamp to 0... >>> [00:00:01.797430] Testing receive rate 10.000000 Msps on 1 channels >>> >>> On Wed, Jul 17, 2019 at 4:39 PM Nate Temple <nate.tem...@ettus.com> >>> wrote: >>> >>>> Hi Sumit, >>>> >>>> If you run benchmark_rate for an extend period of time, do you see any >>>> sequence errors? >>>> >>>> /usr/local/lib/uhd/examples/benchmark_rate --rx_rate 10e6 --duration 600 >>>> >>>> >>>> Regards, >>>> Nate Temple >>>> >>>> On Wed, Jul 17, 2019 at 7:34 AM Sumit Kumar <cog...@gmail.com> wrote: >>>> >>>>> Hi Nate, >>>>> Yes I addressed the first 2 points you mentioned. >>>>> >>>>> john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$ >>>>> sudo ./benchmark_tx.py -f 2.45G -S 10 >>>>> linux; GNU C++ version 5.3.1 20151219; Boost_105800; >>>>> UHD_003.009.002-0-unknown >>>>> >>>>> Using Volk machine: avx_64_mmx_orc >>>>> -- Opening a USRP2/N-Series device... >>>>> -- Current recv frame size: 1472 bytes >>>>> -- Current send frame size: 1472 bytes >>>>> >>>>> No gain specified. >>>>> Setting gain to 15.750000 (from [0.000000, 31.500000]) >>>>> >>>>> ..............................................................................................SS.SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS.SSSS..S......SS.S......SS.....S....S...S.S.......S....S........^C >>>>> >>>>> I am using ./benchmark_tx.py located >>>>> in gnuradio/gr-digital/examples/narrowband >>>>> >>>>> >>>>> >>>>> On Wed, Jul 17, 2019 at 4:25 PM Nate Temple <nate.tem...@ettus.com> >>>>> wrote: >>>>> >>>>>> Hi Sumit, >>>>>> >>>>>> A couple things to address: >>>>>> >>>>>> 1) Enable Thread priority scheduling on your host >>>>>> >>>>>> Note it is throwing a warning in the output: "[WARNING] [UHD] Unable >>>>>> to set the thread priority. Performance may be negatively affected." >>>>>> >>>>>> >>>>>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Thread_priority_scheduling >>>>>> >>>>>> >>>>>> 2) Adjust your network buffers >>>>>> >>>>>> " >>>>>> [WARNING] [UDP] The send buffer could not be resized sufficiently. >>>>>> Target sock buff size: 2500000 bytes. >>>>>> Actual sock buff size: 1048576 bytes. >>>>>> See the transport application notes on buffer resizing. >>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>> [WARNING] [UDP] The send buffer could not be resized sufficiently. >>>>>> Target sock buff size: 2500000 bytes. >>>>>> Actual sock buff size: 1048576 bytes. >>>>>> See the transport application notes on buffer resizing. >>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>> " >>>>>> >>>>>> https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#N2xx >>>>>> >>>>>> >>>>>> What is the command you're using to transmit(which utility and args?) >>>>>> >>>>>> >>>>>> Regards, >>>>>> Nate Temple >>>>>> >>>>>> On Wed, Jul 17, 2019 at 7:06 AM Sumit Kumar via USRP-users < >>>>>> usrp-users@lists.ettus.com> wrote: >>>>>> >>>>>>> Following is what I am getting after the command you asked to run. >>>>>>> The 192.168.10.5 gives SSSSSSS. >>>>>>> >>>>>>> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/utils$ >>>>>>> ./usrp_burn_mb_eeprom --read-all --args "addr=192.168.10.5" >>>>>>> Creating USRP device from address: addr=192.168.10.5 >>>>>>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; >>>>>>> UHD_3.15.0.git-1-gf83faf28 >>>>>>> [INFO] [USRP2] Opening a USRP2/N-Series device... >>>>>>> [INFO] [USRP2] Current recv frame size: 1472 bytes >>>>>>> [INFO] [USRP2] Current send frame size: 1472 bytes >>>>>>> [WARNING] [UDP] The send buffer could not be resized sufficiently. >>>>>>> Target sock buff size: 2500000 bytes. >>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>> See the transport application notes on buffer resizing. >>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>> [WARNING] [UDP] The send buffer could not be resized sufficiently. >>>>>>> Target sock buff size: 2500000 bytes. >>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>> See the transport application notes on buffer resizing. >>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>> [WARNING] [UDP] The send buffer could not be resized sufficiently. >>>>>>> Target sock buff size: 2500000 bytes. >>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>> See the transport application notes on buffer resizing. >>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>> [WARNING] [UHD] Unable to set the thread priority. Performance may >>>>>>> be negatively affected. >>>>>>> Please see the general application notes in the manual for >>>>>>> instructions. >>>>>>> EnvironmentError: OSError: error in pthread_setschedparam >>>>>>> >>>>>>> Fetching current settings from EEPROM... >>>>>>> EEPROM ["hardware"] is "2576" >>>>>>> EEPROM ["revision"] is "" >>>>>>> EEPROM ["product"] is "" >>>>>>> EEPROM ["mac-addr"] is "a0:36:fa:26:34:44" >>>>>>> EEPROM ["ip-addr"] is "192.168.10.5" >>>>>>> EEPROM ["subnet"] is "255.255.255.255" >>>>>>> EEPROM ["gateway"] is "255.255.255.255" >>>>>>> EEPROM ["gpsdo"] is "none" >>>>>>> EEPROM ["serial"] is "E4R14V4UN" >>>>>>> EEPROM ["name"] is "" >>>>>>> >>>>>>> Power-cycle the USRP device for the changes to take effect. >>>>>>> >>>>>>> Done >>>>>>> >>>>>>> >>>>>>> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/utils$ >>>>>>> ./usrp_burn_mb_eeprom --read-all --args "addr=192.168.10.3" >>>>>>> Creating USRP device from address: addr=192.168.10.3 >>>>>>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; >>>>>>> UHD_3.15.0.git-1-gf83faf28 >>>>>>> [INFO] [USRP2] Opening a USRP2/N-Series device... >>>>>>> [INFO] [USRP2] Current recv frame size: 1472 bytes >>>>>>> [INFO] [USRP2] Current send frame size: 1472 bytes >>>>>>> [WARNING] [UDP] The send buffer could not be resized sufficiently. >>>>>>> Target sock buff size: 2500000 bytes. >>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>> See the transport application notes on buffer resizing. >>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>> [WARNING] [UDP] The send buffer could not be resized sufficiently. >>>>>>> Target sock buff size: 2500000 bytes. >>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>> See the transport application notes on buffer resizing. >>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>> [WARNING] [UDP] The send buffer could not be resized sufficiently. >>>>>>> Target sock buff size: 2500000 bytes. >>>>>>> Actual sock buff size: 1048576 bytes. >>>>>>> See the transport application notes on buffer resizing. >>>>>>> Please run: sudo sysctl -w net.core.wmem_max=2500000 >>>>>>> [WARNING] [UHD] Unable to set the thread priority. Performance may >>>>>>> be negatively affected. >>>>>>> Please see the general application notes in the manual for >>>>>>> instructions. >>>>>>> EnvironmentError: OSError: error in pthread_setschedparam >>>>>>> >>>>>>> Fetching current settings from EEPROM... >>>>>>> EEPROM ["hardware"] is "2576" >>>>>>> EEPROM ["revision"] is "" >>>>>>> EEPROM ["product"] is "" >>>>>>> EEPROM ["mac-addr"] is "a0:36:fa:26:34:42" >>>>>>> EEPROM ["ip-addr"] is "192.168.10.3" >>>>>>> EEPROM ["subnet"] is "255.255.255.255" >>>>>>> EEPROM ["gateway"] is "255.255.255.255" >>>>>>> EEPROM ["gpsdo"] is "none" >>>>>>> EEPROM ["serial"] is "E4R14V2UN" >>>>>>> EEPROM ["name"] is "" >>>>>>> >>>>>>> Power-cycle the USRP device for the changes to take effect. >>>>>>> >>>>>>> Done >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 17, 2019 at 3:19 PM Jason Matusiak < >>>>>>> ja...@gardettoengineering.com> wrote: >>>>>>> >>>>>>>> You are right, the table of revisions was for the X-series >>>>>>>> >>>>>>>> try running the command from your prefix: >>>>>>>> src/uhd/host/build/utils/usrp_burn_mb_eeprom --args="type=n200" >>>>>>>> --read-all >>>>>>>> >>>>>>>> don't quote me on the type portion, I don't have a board in front >>>>>>>> of me to see if it is n200 or something else. I //think// that will >>>>>>>> report >>>>>>>> the major and minor revision values (I am grasping at straws here, just >>>>>>>> trying to figure out what the differences might be). >>>>>>>> >>>>>>>> You are connecting the ethernet connections to the two devices >>>>>>>> through the exact same port on your PC? >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> *From:* Sumit Kumar <cog...@gmail.com> >>>>>>>> *Sent:* Wednesday, July 17, 2019 8:24 AM >>>>>>>> *To:* Jason Matusiak <ja...@gardettoengineering.com> >>>>>>>> *Cc:* usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> >>>>>>>> *Subject:* Re: [USRP-users] Sequence Errors N200 >>>>>>>> >>>>>>>> The sticker for sbx shows F33612 and F33814. >>>>>>>> How will this help ? >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jul 17, 2019 at 1:50 PM Jason Matusiak < >>>>>>>> ja...@gardettoengineering.com> wrote: >>>>>>>> >>>>>>>> Sumit, >>>>>>>> >>>>>>>> OK, the last idea I have: >>>>>>>> >>>>>>>> There is a sticker on the back of the N-series devices it *usually* >>>>>>>> says >>>>>>>> the version there, but not always. This has a little info: >>>>>>>> https://kb.ettus.com/About_the_Motherboard_and_Daughtercard_EEPROM_on_USRP_Devices#N200.2F210_EEPROM >>>>>>>> >>>>>>>> Do they match? >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> *From:* Sumit Kumar <cog...@gmail.com> >>>>>>>> *Sent:* Wednesday, July 17, 2019 7:45 AM >>>>>>>> *To:* Jason Matusiak <ja...@gardettoengineering.com> >>>>>>>> *Cc:* usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> >>>>>>>> *Subject:* Re: [USRP-users] Sequence Errors N200 >>>>>>>> >>>>>>>> Hi Jason, >>>>>>>> >>>>>>>> Yes they are consistent, I mean the output of uhd_usrp_probe for >>>>>>>> both N200 is exactly the same (except the ip, serial and mac addr). >>>>>>>> I do not know where the problem is! Hardware or software >>>>>>>> >>>>>>>> Regards >>>>>>>> Sumit >>>>>>>> >>>>>>>> On Wed, Jul 17, 2019 at 1:19 PM Jason Matusiak < >>>>>>>> ja...@gardettoengineering.com> wrote: >>>>>>>> >>>>>>>> I am not really an N-series guy, so this probably won't be >>>>>>>> helpful. Have you tried doing a uhd_usrp_probe on both devices and >>>>>>>> seen >>>>>>>> that the responses are consistent? >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> *From:* USRP-users <usrp-users-boun...@lists.ettus.com> on behalf >>>>>>>> of Sumit Kumar via USRP-users <usrp-users@lists.ettus.com> >>>>>>>> *Sent:* Wednesday, July 17, 2019 7:15 AM >>>>>>>> *To:* usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> >>>>>>>> *Subject:* [USRP-users] Sequence Errors N200 >>>>>>>> >>>>>>>> Hi, >>>>>>>> I am trying transmit using Ettus N200 (call it A) but getting this >>>>>>>> error message on the console >>>>>>>> >>>>>>>> >>>>>>>> SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSUSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................... >>>>>>>> >>>>>>>> I looked for it on google and found these links >>>>>>>> >>>>>>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-May/037495.html >>>>>>>> >>>>>>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-July/032838.html >>>>>>>> >>>>>>>> Both the links suggested problem related to the gigabit port. Then >>>>>>>> I connected another USRP N200 (call it B) to the same laptop and tried >>>>>>>> transmitting using that as there were no such sequence error messages. >>>>>>>> >>>>>>>> This makes me believe there is some problem with the first USRP, >>>>>>>> i.e., A. >>>>>>>> >>>>>>>> Further I tried with different versions of UHD 3.11, UHD 3.15.. but >>>>>>>> its the same. >>>>>>>> >>>>>>>> Receive is good only transmit is throwing error. >>>>>>>> >>>>>>>> Not only with UHD, even in labview, when I transmit, I see nothing >>>>>>>> coming out from the N200 (A). >>>>>>>> >>>>>>>> I am using SBXv2 daughter board. >>>>>>>> >>>>>>>> Any clue! >>>>>>>> >>>>>>>> Regards >>>>>>>> -- >>>>>>>> -- >>>>>>>> Sumit kumar >>>>>>>> Postdoc >>>>>>>> SnT, Luxembourg >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> -- >>>>>>>> Sumit kumar >>>>>>>> Postdoc >>>>>>>> SnT, Luxembourg >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> -- >>>>>>>> Sumit kumar >>>>>>>> Postdoc >>>>>>>> SnT, Luxembourg >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> Sumit kumar >>>>>>> Postdoc >>>>>>> SnT, Luxembourg >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> USRP-users mailing list >>>>>>> USRP-users@lists.ettus.com >>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> -- >>>>> Sumit kumar >>>>> Postdoc >>>>> SnT, Luxembourg >>>>> >>>>> >>>>> >>> >>> -- >>> -- >>> Sumit kumar >>> Postdoc >>> SnT, Luxembourg >>> >>> >>> > > -- > -- > Sumit kumar > Postdoc > SnT, Luxembourg > > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
