On Wed, Jul 17, 2019 at 5:22 PM Nate Temple <nate.tem...@ettus.com
<mailto: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
<mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
<mailto: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
<https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_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
<mailto: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
<mailto: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
<mailto:cog...@gmail.com>>
*Sent:* Wednesday, July 17, 2019
8:24 AM
*To:* Jason Matusiak
<ja...@gardettoengineering.com
<mailto:ja...@gardettoengineering.com>>
*Cc:* usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
<usrp-users@lists.ettus.com
<mailto: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
<mailto: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
<mailto:cog...@gmail.com>>
*Sent:* Wednesday, July 17,
2019 7:45 AM
*To:* Jason Matusiak
<ja...@gardettoengineering.com
<mailto:ja...@gardettoengineering.com>>
*Cc:*
usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
<usrp-users@lists.ettus.com
<mailto: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
<mailto: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
<mailto:usrp-users-boun...@lists.ettus.com>>
on behalf of Sumit Kumar
via USRP-users
<usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>>
*Sent:* Wednesday, July
17, 2019 7:15 AM
*To:*
usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
<usrp-users@lists.ettus.com
<mailto: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
<mailto: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