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

Reply via email to