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 > > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
