On Oct 29, 2013 6:46 PM, "Ian Buckley" ianb@ionconcepts.com wrote:

being starved of new sample data from the transport.

running at, the N200 includes 1MB of transmit buffer which tends to mask
most transport glitches.

that your current setup should be easily capable of supporting this
transmit transport rate.

USRP…ICMP packets are handled in S/W and not in the dedicated H/W used for
the radio, 1mS response is typical.

to transmit on the host, does it use a lot of CPU or memory resources such
that the Host is struggling to keep up?

I don't think the problem is related to PC resources. I have a good
machine, and my application is very simple. It simply streams a precompiled
array of samples representing a rectangular pulses pattern.

that are competing for resources?

with UHD? Try it with options like "benchmark_rate --tx_rate=1e6
--duration=10" , which helps us eliminate any issue specific to your user
code. Does the underflow problem seem to change in severity proportional
with the sample rate?

That's exactly what I was looking for, but I couldn't find! I'll try it
ASAP.

advised by warnings from UHD? Take a look at
http://files.ettus.com/uhd_docs/manual/html/transport.html and
specifically try some experimentation with the net.core.wmem_max value.
Have you made any changes to the MTU value for the interface you are using?

I made all the adjustment that UHD suggested.

it go via switches and is it shared with other network traffic? Are there
any anomalous values reported by the network device driver? For example
using ifconfig, this is what it looks like when the host device driver can
not occasionallly keep up with incoming packets (RX dropped count):

PC and N200 are directly connected with cable. No switches.

Mask:255.255.255.0

GB)

I'll check for drops.

is a good resource…for example the USRP N200 does not support pause frames
over ethernet.

I used ethtool to verify that PC ethernet card speed was effectively set
to gigabit. Autonegotiation is on.

typically show up in laptops, this thread discusses some of those affected:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-December/005825.html

is hidden damage that makes it unreliable.

Already tried with another cable, and  another PC. Nothing changes.

Thank you,
Gaetano.

wrote:

Underflow errors even if the device is correctly connected to my Gbit
ethernet. I'm using the N200 as a transmitter. The sample rate is 1Msps,
therefore, I estimate a TX rate of about 1Msps * 32 = 32Mbps (considering a
stream of 32bit samples). This rate should be completely affordable by the
device. Moreover, the ping delay between my PC and the N200 is about 1ms,
that is a very high value being the two ethernet cards directly connected.

spectrum analyzer. I verified that it is capable of transmitting at least
600Mbps. Is anybody experiencing the same issue? There is something I can
do to find the problem?

I performed the test you suggested. It seems that everything is ok.
This is the output:

    $ ./uhd/host/build/examples/benchmark_rate --tx_rate=25e6 

--duration=10
linux; GNU C++ version 4.7.3; Boost_104900;
UHD_003.005.004-138-g8521c392

    Creating the usrp device with: ...
    -- Opening a USRP2/N-Series device...
    -- Current recv frame size: 1472 bytes
    -- Current send frame size: 1372 bytes
    Using Device: Single USRP:
      Device: USRP2 / N-Series Device
      Mboard 0: N200r4
      RX Channel: 0
        RX DSP: 0
        RX Dboard: A
        RX Subdev: XCVR2450 RX
      TX Channel: 0
        TX DSP: 0
        TX Dboard: A
        TX Subdev: XCVR2450 TX

    Testing transmit rate 25.000000 Msps on 1 channels

    Benchmark rate summary:
      Num received samples:    0
      Num dropped samples:     0
      Num overflows detected:  0
      Num transmitted samples: 250237962
      Num sequence errors:     0
      Num underflows detected: 0


    Done!

No drops or errors in the ethernet card statistics.

My script keeps showing an Underflow error with a sample rate of 5Msps:

    $ ./test.py
    linux; GNU C++ version 4.7.3; Boost_104900; 

UHD_003.005.004-138-g8521c392

    -- Opening a USRP2/N-Series device...
    -- Current recv frame size: 1472 bytes
    -- Current send frame size: 1444 bytes
    U

This is my script (excluding imports) if you want to have a look :)

pat = {
"p_width"  : 2e-6,      # pulse width in seconds
"p_space"  : 400e-6,  # space between pulses in seconds
"p_num"    : 12,        # number of pulses
}

class pfb_top_block(gr.top_block):
def init(self):
# plot, usrp, file
gr.top_block.init(self)
# Sampling rate
self.fs = 5e6
amp = 1.0
# Total length of the pattern
totlen = (pat["p_width"] * pat["p_num"] +
pat["p_space"] * (pat["p_num"] - 1))
# Total number of samples
N = int(scipy.floor(totlenself.fs))
# Signal samples data
data = scipy.zeros(N, dtype=complex)
# Number of samples composing a pulse
pulse_samples = int(scipy.floor(pat["p_width"] * self.fs))
# Number of samples composing the spacing between samples
spacing_samples = int(scipy.floor(pat["p_space"] * self.fs))
offset = 0
for j in range(pat["p_num"]):
for i in range(pulse_samples):
data[offset+i] = complex(amp, amp)
offset += pulse_samples + spacing_samples
######## Connections ########
_input = blocks.vector_source_c(data, False)
stream_args = uhd.stream_args('fc32')
self._usrp = uhd.usrp_sink("", stream_args=stream_args)
self._usrp.set_samp_rate(self.fs)
# center freq 5 GHz
self._usrp.set_center_freq(50001e6, 0)
self._usrp.set_gain(10.0, 0)
self.connect(_input, self._usrp)

def main():
tb = pfb_top_block()
tb.run()
# print empty line
print

if name == "main":
main()

Do you see something wrong?

Thanks,
Gaetano.

On Tue, Oct 29, 2013 at 7:18 PM, Gaetano Catalli
<gaetano.catalli@gmail.com mailto:gaetano.catalli@gmail.com> wrote:

 On Oct 29, 2013 6:46 PM, "Ian Buckley" <ianb@ionconcepts.com
 <mailto:ianb@ionconcepts.com>> wrote:

 transmit DSP being starved of new sample data from the transport.

 are running at, the N200 includes 1MB of transmit buffer which
 tends to mask most transport glitches.

 indication that your current setup should be easily capable of
 supporting this transmit transport rate.

 presence of the USRP…ICMP packets are handled in S/W and not in
 the dedicated H/W used for the radio, 1mS response is typical.

 using to transmit on the host, does it use a lot of CPU or memory
 resources such that the Host is struggling to keep up?

 I don't think the problem is related to PC resources. I have a
 good machine, and my application is very simple. It simply streams
 a precompiled array of samples representing a rectangular pulses
 pattern.

 time that are competing for resources?

 supplied with UHD? Try it with options like "benchmark_rate
 --tx_rate=1e6 --duration=10" , which helps us eliminate any issue
 specific to your user code. Does the underflow problem seem to
 change in severity proportional with the sample rate?

 That's exactly what I was looking for, but I couldn't find! I'll
 try it ASAP.

 sometimes advised by warnings from UHD? Take a look at
 http://files.ettus.com/uhd_docs/manual/html/transport.html and
 specifically try some experimentation with the net.core.wmem_max
 value. Have you made any changes to the MTU value for the
 interface you are using?

 I made all the adjustment that UHD suggested.

 Or does it go via switches and is it shared with other network
 traffic? Are there any anomalous values reported by the network
 device driver? For example using ifconfig, this is what it looks
 like when the host device driver can not occasionallly keep up
 with incoming packets (RX dropped count):

 PC and N200 are directly connected with cable. No switches.

  Mask:255.255.255.0

 overruns:0 frame:0

 carrier:0

 (216.3 GB)

 I'll check for drops.

 ethtool is a good resource…for example the USRP N200 does not
 support pause frames over ethernet.

 I used ethtool to verify that PC ethernet card speed was
 effectively set to gigabit. Autonegotiation is on.

 that typically show up in laptops, this thread discusses some of
 those affected:
 http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-December/005825.html

 there is hidden damage that makes it unreliable.

 Already tried with another cable, and  another PC. Nothing changes.

 Thank you,
 Gaetano.

 <gaetano.catalli@gmail.com <mailto:gaetano.catalli@gmail.com>> wrote:

 Underflow errors even if the device is correctly connected to my
 Gbit ethernet. I'm using the N200 as a transmitter. The sample
 rate is 1Msps, therefore, I estimate a TX rate of about 1Msps * 32
 = 32Mbps (considering a stream of 32bit samples). This rate should
 be completely affordable by the device. Moreover, the ping delay
 between my PC and the N200 is about 1ms, that is a very high value
 being the two ethernet cards directly connected.

 a spectrum analyzer. I verified that it is capable of transmitting
 at least 600Mbps. Is anybody experiencing the same issue? There is
 something I can do to find the problem?

**

I performed the test you suggested. It seems that everything is ok. This
is the output:

     $ ./uhd/host/build/examples/benchmark_rate --tx_rate=25e6

--duration=10
linux; GNU C++ version 4.7.3; Boost_104900;
UHD_003.005.004-138-g8521c392

     Creating the usrp device with: ...
    -- Opening a USRP2/N-Series device...
    -- Current recv frame size: 1472 bytes
    -- Current send frame size: 1372 bytes
    Using Device: Single USRP:
      Device: USRP2 / N-Series Device
      Mboard 0: N200r4
      RX Channel: 0
        RX DSP: 0
        RX Dboard: A
        RX Subdev: XCVR2450 RX
      TX Channel: 0
        TX DSP: 0
        TX Dboard: A
        TX Subdev: XCVR2450 TX

     Testing transmit rate 25.000000 Msps on 1 channels

     Benchmark rate summary:
      Num received samples:    0
      Num dropped samples:     0
      Num overflows detected:  0
      Num transmitted samples: 250237962
      Num sequence errors:     0
      Num underflows detected: 0


     Done!

No drops or errors in the ethernet card statistics.

My script keeps showing an Underflow error with a sample rate of 5Msps:

     $ ./test.py
    linux; GNU C++ version 4.7.3; Boost_104900;

UHD_003.005.004-138-g8521c392

     -- Opening a USRP2/N-Series device...
    -- Current recv frame size: 1472 bytes
    -- Current send frame size: 1444 bytes
    U

This is my script (excluding imports) if you want to have a look :)

pat = {
"p_width"  : 2e-6,      # pulse width in seconds
"p_space"  : 400e-6,  # space between pulses in seconds
"p_num"    : 12,        # number of pulses
}

class pfb_top_block(gr.top_block):
def init(self):
# plot, usrp, file
gr.top_block.init(self)

     # Sampling rate
     self.fs = 5e6
     amp = 1.0

     # Total length of the pattern
     totlen = (pat["p_width"] * pat["p_num"] +
                 pat["p_space"] * (pat["p_num"] - 1))

     # Total number of samples
     N = int(scipy.floor(totlen*self.fs))

     # Signal samples data
     data = scipy.zeros(N, dtype=complex)

     # Number of samples composing a pulse
     pulse_samples = int(scipy.floor(pat["p_width"] * self.fs))
     # Number of samples composing the spacing between samples
     spacing_samples = int(scipy.floor(pat["p_space"] * self.fs))

     offset = 0
     for j in range(pat["p_num"]):
         for i in range(pulse_samples):
             data[offset+i] = complex(amp, amp)
         offset += pulse_samples + spacing_samples

     ######## Connections ########
     _input = blocks.vector_source_c(data, False)

     stream_args = uhd.stream_args('fc32')
     self._usrp = uhd.usrp_sink("", stream_args=stream_args)
     self._usrp.set_samp_rate(self.fs)
      # center freq 5 GHz
     self._usrp.set_center_freq(5000*1e6, 0)
     self._usrp.set_gain(10.0, 0)
     self.connect(_input, self._usrp)

def main():
tb = pfb_top_block()
tb.run()
# print empty line
print

if name == "main":
main()

Do you see something wrong?

Thanks,
Gaetano.

On Tue, Oct 29, 2013 at 7:18 PM, Gaetano Catalli <
gaetano.catalli@gmail.com> wrote:

You're getting one underrun, or a continous stream of them?

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org

USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

On Wed, Oct 30, 2013 at 2:56 PM, Marcus D. Leech <mleech@ripnet.com
mailto:mleech@ripnet.com> wrote:

 __

 You're getting one underrun, or a continous stream of them?




 -- 
 Marcus Leech
 Principal Investigator
 Shirleys Bay Radio Astronomy Consortium
 http://www.sbrac.org


 _______________________________________________
 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

--
gaetano catalli