Tried 3 different power supplies, still the same. SSSSSS :-/

On Wed, Jul 17, 2019 at 5:20 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 07/17/2019 11:10 AM, Sumit Kumar via USRP-users 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
>
>
> Purely on a hunch, try swapping power supplies.
>
>
> 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 
> listUSRP-users@lists.ettus.comhttp://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
>


-- 
-- 
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