Hi Sumit, Actually, I had a typo in the command, that previous benchmark_rate command only tested RX, can you try passing the --tx_rate param and see if it will produce sequence errors using benchmark_rate
./benchmark_rate --tx_rate 10e6 --duration 600 Regards, Nate Temple On Wed, Jul 17, 2019 at 8:27 AM Sumit Kumar <cog...@gmail.com> wrote: > Ok I will do this.. but why the transmission with other USRP is working > fine ? > > On Wed, Jul 17, 2019 at 5:22 PM Nate Temple <nate.tem...@ettus.com> wrote: > >> 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 >>> >>> >>> > > -- > -- > 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
