Re: [USRP-users] Command inside streaming

[Андрей 1 via USRP-users]

After getting UHD_ERROR_IO, I stop receiving data and have to reopening then
device
(uhd_rx_streamer_free,uhd_usrp_free,uhd_usrp_make,uhd_rx_streamer_make,uhd_usrp_get_rx_stream
and other).
My questionIf I can call a function uhd_usrp_get_time_now inside streaming why
occurs error that discribe early?Can I call functions inside a stream as often 
as
I want?

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

Re: [USRP-users] Duplicate ip addr issue X310

[Jonathan Liang via USRP-users]

Dear Hanqing,

I got the same error as what you described in your email. Did you solve that 
problem by yourself? If yes, would you mind telling me how to solve that?

Many thanks in advanced.

Regards,
Jonathan

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

Re: [USRP-users] Spikes at beginning and end of transmission

[Brais Ares via USRP-users]

Thank you Marcus once again, crystal clear now.

2018-03-21 16:17 GMT+01:00 Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com>:

> On 03/21/2018 03:51 AM, Brais Ares via USRP-users wrote:
>
> ​Hi,
>
> I can see a similar spike, a few microseconds long, at the beggining of
> each transmission (see figure attached).
> However I'm not using a B2xx, but a *E310*. Could this also be a hardware
> problem or just its normal behaviour?
>
> Regards.
> Brais.​
>
> Small transients at the beginning and end of transmissions are pretty
> normal -- with both analog hardware and DSP contributions to the
>   phenomenon.
>
> The various pieces of analog hardware (mixers, switches, amplifiers,
> synthesizers) cannot reach steady-state operation instantaneously, so there
> will
>   always be some transient from that.  Further, the filters in the DUC
> chain will necessarily experience a transient as new data is loaded into
> them that
>   is completely unrelated to any previous samples--they will be processing
> a discontinuity in signal, and there will be some transient response as a
> result.
>
>
>
>
>
>
> 2018-03-15 20:56 GMT+01:00 Michael West via USRP-users <
> usrp-users@lists.ettus.com>:
>
>> Hi Thomas,
>>
>> This is a known hardware issue with earlier revisions of the B200mini and
>> has been fixed on newer versions.  Please contact supp...@ettus.com and
>> they can help get the boards reworked.
>>
>> Regards,
>> Michael
>>
>> On Sun, Feb 25, 2018 at 6:54 AM, Thomas Teisberg via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I'm sorry, which thread are you referring to?
>>>
>>> I have tried implementing the changes in the thread I originally linked
>>> to and it doesn't seem to have made any difference.
>>>
>>> Best,
>>> Thomas
>>>
>>> On Feb 25, 2018 4:52 AM, "Steven Knudsen"  wrote:
>>>
 Hi,

 This is a known problem with the B20xmini. Have a look at this thread
 and then follow it up.

 You are right, you are seeing caps charge and discharge, basically.

 Since I made the changes myself on my units, I am not sure where things
 were left with Ettus and their policy for fixing the problem. But I can say
 that once you make the changes, the transients are gone and the minis work
 really well.

 regards,

 steven


 On Sat, Feb 24, 2018 at 3:25 PM, Thomas Teisberg via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> I'm working on a radar project that requires sending a series of short
> pulses. Looking at the pulses on a scope, I'm seeing large voltage spikes
> at the beginning and the end of each transmission.
>
> As shown in the attached screenshot, before the transmission starts,
> there is a 90 mV spike lasting about 10 us. After the transmission, 
> there's
> a -25 mV spike lasting about 20 us.
>
> The setup for this is simply a USRP B205mini-i connected to a 50 ohm
> input on a scope through a 30 dB attenuator. The signal is at 435 MHz with
> the scope sampling at 20 Gsps.
>
> Our initial thought was that we must be seeing some effects of some of
> the RF frontend components turning on and off. I found this previous
> mailing list post and tried the suggested fix in b200_impl.cpp but nothing
> changed:
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/
> 2015-January/012269.html
>
> Any ideas why we might be seeing these spikes or what we could do
> about it? Does the fix suggested in the above mailing list post still 
> apply
> to the current codebase?
>
> Thanks,
> Thomas
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>


 --
 K. Steven Knudsen, Ph.D., P.Eng.

>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://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
>>
>>
>
>
>
>
> ___
> 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
>
>


-- 

[image: logo_170x100px.png] 

Brais Ares Fernández
Investigador - Desarrollador | Área de Comunicaciones Avanzadas
Researcher - Developer | Advanced Communications Department

Ph. (+34) 986 120 430  Ext. 3030
ba...@gradiant.org  |  www.gradiant.org

[image: Iconos Redes Sociales GRD Firma e

[USRP-users] RFNoC spp rate limitation

[Sebastian Leutner via USRP-users]

Hi all,

when working with RFNoC at 200 MSps on the X310 using 10GbE I experience 
overruns when using less than 512 samples per packet (spp).
A simple flow graph [RFNoC Radio] -> [RFNoC FIFO] -> [Null sink] with the 
spp stream arg set at the RFNoC Radio block shows the following network 
utilization:


spp | throughput [Gbps]

1024 | 6.49
512 | 6.58
256 | 3.60
 64 | 0.70

Although I understand that the total load will increase a little bit for 
smaller packets due to increased overhead (headers) as seen from spp=1024 
to spp=512, I find it confusing that so many packets are dropped for spp <= 
256.


Total goodput should be 200 MSps * 4 byte per sample (sc16) = 800 MBps = 
6.40 Gbps.


Is RFNoC somehow limited to a certain number of packets per second 
(regardless of their size)?
Could this be resolved by increasing the STR_SINK_FIFOSIZE noc_shell 
parameter of any blocks connected to the RFNoC Radio?


I would like to use spp=64 because that is the size of the RFNoC FFT I want 
to use. I am using UHD 4.0.0.rfnoc-devel-409-gec9138eb.


Any help or ideas appreciated!

Best,
Sebastian



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

Re: [USRP-users] RFNoC spp rate limitation

[Marcus D. Leech via USRP-users]

On 03/22/2018 09:45 AM, Sebastian Leutner via USRP-users wrote:

Hi all,

when working with RFNoC at 200 MSps on the X310 using 10GbE I 
experience overruns when using less than 512 samples per packet (spp).
A simple flow graph [RFNoC Radio] -> [RFNoC FIFO] -> [Null sink] with 
the spp stream arg set at the RFNoC Radio block shows the following 
network utilization:


spp | throughput [Gbps]

1024 | 6.49
512 | 6.58
256 | 3.60
 64 | 0.70

Although I understand that the total load will increase a little bit 
for smaller packets due to increased overhead (headers) as seen from 
spp=1024 to spp=512, I find it confusing that so many packets are 
dropped for spp <= 256.


Total goodput should be 200 MSps * 4 byte per sample (sc16) = 800 MBps 
= 6.40 Gbps.


Is RFNoC somehow limited to a certain number of packets per second 
(regardless of their size)?
Could this be resolved by increasing the STR_SINK_FIFOSIZE noc_shell 
parameter of any blocks connected to the RFNoC Radio?


I would like to use spp=64 because that is the size of the RFNoC FFT I 
want to use. I am using UHD 4.0.0.rfnoc-devel-409-gec9138eb.


Any help or ideas appreciated!

Best,
Sebastian

This is almost certainly an interrupt-rate issue having to do with your 
ethernet controller, and nothing to do with RFNoC, per se.


If you're on Linux, try:

ethtool --coalesce   adaptive-rx on
ethtool --coalesce  adaptive-tx on




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

[USRP-users] Command inside streaming repeat

[Андрей 1 via USRP-users]

 Пересылаемое сообщение 
От: Андрей 1 
Дата: 22.03.2018, 10:03
Кому: Usrp Users 
Тема: RE: RE: Command inside streaming
After getting UHD_ERROR_IO, I stop receiving data and have to reopening then
device
(uhd_rx_streamer_free,uhd_usrp_free,uhd_usrp_make,uhd_rx_streamer_make,uhd_usrp_get_rx_stream
and other).
My questionIf I can call a function uhd_usrp_get_time_now inside streaming why
occurs error that discribe early?Can I call functions inside a stream as often 
as
I want?

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

Re: [USRP-users] RFNoC spp rate limitation

[Sebastian Leutner via USRP-users]

Hi all,

when working with RFNoC at 200 MSps on the X310 using 10GbE I
experience overruns when using less than 512 samples per packet (spp).
A simple flow graph [RFNoC Radio] -> [RFNoC FIFO] -> [Null sink] with
the spp stream arg set at the RFNoC Radio block shows the following
network utilization:

spp | throughput [Gbps]

1024 | 6.49
512 | 6.58
256 | 3.60
 64 | 0.70

Although I understand that the total load will increase a little bit
for smaller packets due to increased overhead (headers) as seen from
spp=1024 to spp=512, I find it confusing that so many packets are
dropped for spp <= 256.

Total goodput should be 200 MSps * 4 byte per sample (sc16) = 800 MBps
= 6.40 Gbps.

Is RFNoC somehow limited to a certain number of packets per second
(regardless of their size)?
Could this be resolved by increasing the STR_SINK_FIFOSIZE noc_shell
parameter of any blocks connected to the RFNoC Radio?

I would like to use spp=64 because that is the size of the RFNoC FFT I
want to use. I am using UHD 4.0.0.rfnoc-devel-409-gec9138eb.

Any help or ideas appreciated!

Best,
Sebastian


This is almost certainly an interrupt-rate issue having to do with your
ethernet controller, and nothing to do with RFNoC, per se.

If you're on Linux, try:

ethtool --coalesce   adaptive-rx on
ethtool --coalesce  adaptive-tx on


Thanks Marcus for your quick response. Unfortunately, that did not help. 
Also, `ethtool -c enp1s0f0` still reports "Adaptive RX: off  TX: off" 
afterwards. I also tried changing `rx-usecs` which reported correctly but 
did not help either. I am using Intel 82599ES 10-Gigabit SFI/SFP+ 
controller with the driver ixgbe (version: 5.1.0-k) on Ubuntu 16.04.


Do you know anything else I could try?

Thanks,
Sebastian









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

[USRP-users] Getting started with FPGA and RFNoC developement

[TIMMEN Koen via USRP-users]

Hello,

First of all I would like to mention that I am not sure if this is the right 
location to ask these type of questions. However, I tried to find answers to my 
questions elsewhere but couldn't find a better suited location, so I hope I'm 
not at the wrong address and causing too much clutter in the e-mail list.

My experience with USRPs is almost nonexistent. Over the last few weeks I have 
looked around on the internet, learning about the concepts of FPGAs and HDL 
coding and I followed the Getting Started Guide for RFNoC. I am familiar with 
signal processing and the required mathematics and I would like to apply this 
knowledge in the domain of FPGAs, possibly while using RFNoC. This, I will be 
doing within the scope of an assignment that was given to me: what needs to be 
done is to set-up a USRP X310 with a real time signal generation module. 
Currently, this module is already up and running on a USRP N210 and all HDL 
code and host code is available to me. So all that needs to be done, is to use 
the existing HDL code and port it to another device. At least.. that's how I 
interpret the task. Like I said, I am new to the USRP field and I have 
difficulties approaching it. Where do I get started? Do I need to know in-depth 
HDL coding etc.

Here are some of the questions I have, I would like to thank anyone who is kind 
enough to reply to them in advance for answering:

· HDL code is device independent, correct? Giving that the new FPGA has 
enough available hardware to synthesize the code, it shouldn't be a problem to 
reuse the HDL code on a different device. So my thinking was that I could 
simply keep all the code that was created by someone skilled on the subject and 
simply create a new device specific image and no changes would be required. Is 
this correct or am I too naïve about this? (My attempts at doing this using 
Vivado, were useless and I can't figure out what I am doing wrong.)

· The existing HDL code is written in VHDL, but upon following the 
RFNoC getting started guide, I noticed the rfnocmodtool produces Verilog 
skeleton code. Is it also possible to make this work with the code I currently 
have or will I have to translate the code into Verilog?

· Will RFNoC be a useful tool in fulfilling this task?

· There are many ready to use RFNoC blocks available through the ettus 
open source library. But I have trouble understanding what they are used for... 
where can I find a description of these blocks? Normally I would expect the 
function of a block written in the code itself. And since I do not read HDL 
code that well, the meaning of the code is not directly obvious to me.

· To close off, I realize that maybe I am too much a beginner to start 
this project. In that case, where should I begin? Is a HDL coding course the 
place to start?

Kind regards,

Koen


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

Re: [USRP-users] RFNoC spp rate limitation

[Marcus D. Leech via USRP-users]

On 03/22/2018 12:41 PM, Sebastian Leutner via USRP-users wrote:

Hi all,

when working with RFNoC at 200 MSps on the X310 using 10GbE I
experience overruns when using less than 512 samples per packet (spp).
A simple flow graph [RFNoC Radio] -> [RFNoC FIFO] -> [Null sink] with
the spp stream arg set at the RFNoC Radio block shows the following
network utilization:

spp | throughput [Gbps]

1024 | 6.49
512 | 6.58
256 | 3.60
 64 | 0.70

Although I understand that the total load will increase a little bit
for smaller packets due to increased overhead (headers) as seen from
spp=1024 to spp=512, I find it confusing that so many packets are
dropped for spp <= 256.

Total goodput should be 200 MSps * 4 byte per sample (sc16) = 800 MBps
= 6.40 Gbps.

Is RFNoC somehow limited to a certain number of packets per second
(regardless of their size)?
Could this be resolved by increasing the STR_SINK_FIFOSIZE noc_shell
parameter of any blocks connected to the RFNoC Radio?

I would like to use spp=64 because that is the size of the RFNoC FFT I
want to use. I am using UHD 4.0.0.rfnoc-devel-409-gec9138eb.

Any help or ideas appreciated!

Best,
Sebastian


This is almost certainly an interrupt-rate issue having to do with your
ethernet controller, and nothing to do with RFNoC, per se.

If you're on Linux, try:

ethtool --coalesce   adaptive-rx on
ethtool --coalesce  adaptive-tx on


Thanks Marcus for your quick response. Unfortunately, that did not 
help. Also, `ethtool -c enp1s0f0` still reports "Adaptive RX: off TX: 
off" afterwards. I also tried changing `rx-usecs` which reported 
correctly but did not help either. I am using Intel 82599ES 10-Gigabit 
SFI/SFP+ controller with the driver ixgbe (version: 5.1.0-k) on Ubuntu 
16.04.


Do you know anything else I could try?

Thanks,
Sebastian
The basic problem is that in order to achieve good performance at 
very-high sample-rates, jumbo-frames are required, and using a very 
small SPP implies

  very small frames, which necessarily leads to poor ethernet performance.

Do you actually need the FFT results to appear at the host at 
"real-time" rates, or can you do an integrate-and-dump within RFNoC, to 
reduce host side

  traffic?



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

Re: [USRP-users] Getting started with FPGA and RFNoC developement

[Nick Foster via USRP-users]

Replies inline.

On Thu, Mar 22, 2018 at 9:48 AM TIMMEN Koen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
>
> First of all I would like to mention that I am not sure if this is the
> right location to ask these type of questions. However, I tried to find
> answers to my questions elsewhere but couldn’t find a better suited
> location, so I hope I’m not at the wrong address and causing too much
> clutter in the e-mail list.
>
>
>
> My experience with USRPs is almost nonexistent. Over the last few weeks I
> have looked around on the internet, learning about the concepts of FPGAs
> and HDL coding and I followed the Getting Started Guide for RFNoC. I am
> familiar with signal processing and the required mathematics and I would
> like to apply this knowledge in the domain of FPGAs, possibly while using
> RFNoC. This, I will be doing within the scope of an assignment that was
> given to me: what needs to be done is to set-up a USRP X310 with a real
> time signal generation module. Currently, this module is already up and
> running on a USRP N210 and all HDL code and host code is available to me.
> So all that needs to be done, is to use the existing HDL code and port it
> to another device. At least.. that’s how I interpret the task. Like I said,
> I am new to the USRP field and I have difficulties approaching it. Where do
> I get started? Do I need to know in-depth HDL coding etc.
>

You will have to have a pretty solid understanding of HDL, yes. Do I have
this right -- you inherited an existing N210 HDL design (not the stock
code, but a custom build), and you're responsible for porting it to X310?


>
>
> Here are some of the questions I have, I would like to thank anyone who is
> kind enough to reply to them in advance for answering:
>
> · HDL code is device independent, correct? Giving that the new
> FPGA has enough available hardware to synthesize the code, it shouldn’t be
> a problem to reuse the HDL code on a different device. So my thinking was
> that I could simply keep all the code that was created by someone skilled
> on the subject and simply create a new device specific image and no changes
> would be required. Is this correct or am I too naïve about this? (My
> attempts at doing this using Vivado, were useless and I can’t figure out
> what I am doing wrong.)
>
HDL code is nominally device independent, for the simplest cases. In every
part which interfaces with actual hardware it will be extremely
device-dependent. In the case of the N210 design you have, while the core
custom signal processing code which your predecessor created may (or may
not!) be easily portable, the surrounding HDL which composes the rest of
the design is 100% specific to the N210.


> · The existing HDL code is written in VHDL, but upon following
> the RFNoC getting started guide, I noticed the rfnocmodtool produces
> Verilog skeleton code. Is it also possible to make this work with the code
> I currently have or will I have to translate the code into Verilog?
>
You can wrap VHDL modules into Verilog designs.


> · Will RFNoC be a useful tool in fulfilling this task?
>
Yes, but -- before you go anywhere near RFNoC or any hardware at all, I
suggest you spend some time on an intermediate task. That is, creating a
testbench with which you can isolate the relevant DSP code, learn how it
works, and wrap it into something that can be used in an RFNoC block. You
will be best served if you create an AXI4 Stream interface to the DSP code
-- if you are lucky, it already uses an AXI4 Stream interface, in which
case your job gets easier.

Once you have a good understanding of the custom code, and once you have it
isolated into a testbench using AXI4 Streams to interface to it, you can
wrap it into an RFNoC block fairly easily, and at that point you can use it
in an X310 design.


> · There are many ready to use RFNoC blocks available through the
> ettus open source library. But I have trouble understanding what they are
> used for… where can I find a description of these blocks? Normally I would
> expect the function of a block written in the code itself. And since I do
> not read HDL code that well, the meaning of the code is not directly
> obvious to me.
>

Unfortunately documentation is not RFNoC's strong suit. The code is still
the best documentation as to the function of these blocks.


> · To close off, I realize that maybe I am too much a beginner to
> start this project. In that case, where should I begin? Is a HDL coding
> course the place to start?
>

I think that would be a good place to start! I wouldn't look at that (or
anything) as a hard prerequisite. Better to look at it as something which
will certainly speed your understanding and get you to a solution faster.

Nick


>
>
> Kind regards,
>
>
>
> Koen
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-use

[USRP-users] RFNoC Support for TwinRX

[Adams, Andrew L. via USRP-users]

We are currently using a TwinRX daughterboard on a X310 USRP.  We have had 
little success using rfnoc-devel branches of UHD (software and FPGA 
repositories) with the TwinRX card.  Using the latest rfnoc-devel code, the 
TwinRX card only works (i.e., we see our signal coming from the radio) about 
10-20% of the time.  When it doesn't work, the flowgraph continues to run as if 
nothing is wrong, but there is no signal present (I/Q samples don't seem valid; 
they are very close to zero).  This issue can also be reproduced with the 
simplest flowgraph.  This issue led us to believe that it is an incompatibility 
issue between the hardware and the latest rfnoc-devel version.  Therefore, we 
began experimenting with the formal release of UHD: 3.10.3.  The daughterboard 
appears to function correctly with the 3.10.3 release.  Is the TwinRX 
daughterboard supported by RFNOC?

Andrew Adams

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

Re: [USRP-users] RFNoC Support for TwinRX

[Derek Kozel via USRP-users]

Hello Adams,

Yes, the TwinRX Rev A and B work with RFNoC, but the rfnoc-devel branch may
currently have some regressions. We are in the process of updating the
rfnoc-devel branch with many changes from the master branch including
support for the TwinRX Rev C. We will be doing regression testing of the
rfnoc-devel branch with all revisions of the TwinRX next week. I do not
know the timeline for pushing the updated rfnoc-devel branch to the public
repository, but I believe that it will be shortly after the testing.

Regards,
Derek

On Thu, Mar 22, 2018 at 5:55 PM, Adams, Andrew L. via USRP-users <
usrp-users@lists.ettus.com> wrote:

> We are currently using a TwinRX daughterboard on a X310 USRP.  We have had
> little success using rfnoc-devel branches of UHD (software and FPGA
> repositories) with the TwinRX card.  Using the latest rfnoc-devel code, the
> TwinRX card only works (i.e., we see our signal coming from the radio)
> about 10-20% of the time.  When it doesn’t work, the flowgraph continues to
> run as if nothing is wrong, but there is no signal present (I/Q samples
> don’t seem valid; they are very close to zero).  This issue can also be
> reproduced with the simplest flowgraph.  This issue led us to believe that
> it is an incompatibility issue between the hardware and the latest
> rfnoc-devel version.  Therefore, we began experimenting with the formal
> release of UHD: 3.10.3.  The daughterboard appears to function correctly
> with the 3.10.3 release.  Is the TwinRX daughterboard supported by RFNOC?
>
>
>
> Andrew Adams
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://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

Re: [USRP-users] RFNoC spp rate limitation

[Sebastian Leutner via USRP-users]

Hi all,

when working with RFNoC at 200 MSps on the X310 using 10GbE I
experience overruns when using less than 512 samples per packet (spp).
A simple flow graph [RFNoC Radio] -> [RFNoC FIFO] -> [Null sink] with
the spp stream arg set at the RFNoC Radio block shows the following
network utilization:

spp | throughput [Gbps]

1024 | 6.49
512 | 6.58
256 | 3.60
 64 | 0.70

Although I understand that the total load will increase a little bit
for smaller packets due to increased overhead (headers) as seen from
spp=1024 to spp=512, I find it confusing that so many packets are
dropped for spp <= 256.

Total goodput should be 200 MSps * 4 byte per sample (sc16) = 800 MBps
= 6.40 Gbps.

Is RFNoC somehow limited to a certain number of packets per second
(regardless of their size)?
Could this be resolved by increasing the STR_SINK_FIFOSIZE noc_shell
parameter of any blocks connected to the RFNoC Radio?

I would like to use spp=64 because that is the size of the RFNoC FFT I
want to use. I am using UHD 4.0.0.rfnoc-devel-409-gec9138eb.

Any help or ideas appreciated!

Best,
Sebastian


This is almost certainly an interrupt-rate issue having to do with your
ethernet controller, and nothing to do with RFNoC, per se.

If you're on Linux, try:

ethtool --coalesce   adaptive-rx on
ethtool --coalesce  adaptive-tx on


Thanks Marcus for your quick response. Unfortunately, that did not 
help. Also, `ethtool -c enp1s0f0` still reports "Adaptive RX: off TX: 
off" afterwards. I also tried changing `rx-usecs` which reported 
correctly but did not help either. I am using Intel 82599ES 10-Gigabit 
SFI/SFP+ controller with the driver ixgbe (version: 5.1.0-k) on Ubuntu 
16.04.


Do you know anything else I could try?

Thanks,
Sebastian
The basic problem is that in order to achieve good performance at 
very-high sample-rates, jumbo-frames are required, and using a very 
small SPP implies

   very small frames, which necessarily leads to poor ethernet performance.

Do you actually need the FFT results to appear at the host at 
"real-time" rates, or can you do an integrate-and-dump within RFNoC, to 
reduce host side

   traffic?


Yes, I need all the samples. Since it will be a full receiver 
implementation in RFNoC the output to the host will be much less than 
6.40 Gbps but still a decent amount and definitely more than the 0.7 
Gbps I was able to achieve with spp=64.


Do you think that it would suffice to change the packet size at my last 
RFNoC block before the host? I will try out the already available 
packet_resizer block tomorrow.


So the question would be if RFNoC can handle passing packets with spp=64 
at 200 MSps between RFNoC blocks. If this is likely to be a problem, I 
could try wrapping all my HDL code into one RFNoC block and handle the 
packet resizing at input and output of this block. However, I would like 
to avoid this step if possible.


Thanks for your help!

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

[USRP-users] USRP b210 time tagging

[Cho, Daniel J (332C) via USRP-users]

Hello -

I am using the USRP b210 but this questions can be for all USRPs.  Do they 
provide time tagging of the data transmitted and received or is that something 
that I would have to create myself.

Thanks,
Daniel Cho
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP b210 time tagging

[Derek Kozel via USRP-users]

Yes, the data is timestamped. By default it will be times relative to when
the USRP was first turned on, but the set_time_next_pps function can be
used to align the internal time with an external or GPSDO based reference.

http://files.ettus.com/manual/page_sync.html#sync_time

There are examples for transmitting and receiving at set times included
with UHD.
https://github.com/EttusResearch/uhd/blob/8bb15ee133ea98d6755d392b8493966c785291dd/host/examples/rx_timed_samples.cpp#L93
https://github.com/EttusResearch/uhd/blob/8bb15ee133ea98d6755d392b8493966c785291dd/host/examples/tx_timed_samples.cpp#L75

Regards,
Derek

On Thu, Mar 22, 2018 at 8:27 PM, Cho, Daniel J (332C) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello –
>
>
>
> I am using the USRP b210 but this questions can be for all USRPs.  Do they
> provide time tagging of the data transmitted and received or is that
> something that I would have to create myself.
>
>
>
> Thanks,
>
> Daniel Cho
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://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

[USRP-users] RFNoC OFDM Example - Timeout on Chan 0

[Jason Meyer via USRP-users]

I am trying to run the following RFNoC OFDM example on an X310 device:

https://github.com/EttusResearch/gr-ettus/blob/master/examples/rfnoc/rfnoc_ofdm.grc

I am using the virtual source on the receiver side as an input to the OFDM
Schmidl-Cox Sync block, but am getting a timeout. I saw that this is likely
because the Sync block is not detecting a preamble - are there any changes
I need to make to the example design so that the Sync block will detect the
preamble correctly?

Thanks,
Jason Meyer
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC spp rate limitation

[EJ Kreinar via USRP-users]

Hi Sebastian,

> Do you think that it would suffice to change the packet size at my last
RFNoC block before the host? I will try out the already available
packet_resizer block tomorrow.

Yes, this is probably the easiest solution. But, if you're not opposed to
custom HDL, an alternate option could be to create a modified FFT block
that simply outputs an integer number of FFTs within a single packet.

> So the question would be if RFNoC can handle passing packets with spp=64
at 200 MSps between RFNoC blocks

That's a good question... RFNoC blocks all share a crossbar, which runs at
a particular bus_clk rate, so there is a max throughput that the bus can
handle... Each sample on the crossbar is 8 bytes, so you get a total
throughput of bus_clk*8 bytes/second. There's also a header overhead of 16
bytes per packet (or 8 bytes if there's no timestamp).

I'm actually not sure what the current X310 bus_clk rate is set to... I
just noticed a recent commit that supposedly changes bus_clk to 187.5 MHz (
https://github.com/EttusResearch/fpga/commit/d08203f60d3460
a170ad8b3550b478113b7c5968). So I'm not exactly clear what the bus_clk was
set to before that, or on the rfnoc-devel branch...

But unless I'm misunderstanding, having multiple RFNoC blocks running at a
full 200 Msps might saturate the bus? Is that correct?

EJ

On Thu, Mar 22, 2018 at 3:33 PM, Sebastian Leutner via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> when working with RFNoC at 200 MSps on the X310 using 10GbE I
> experience overruns when using less than 512 samples per packet (spp).
> A simple flow graph [RFNoC Radio] -> [RFNoC FIFO] -> [Null sink] with
> the spp stream arg set at the RFNoC Radio block shows the following
> network utilization:
>
> spp | throughput [Gbps]
> 
> 1024 | 6.49
> 512 | 6.58
> 256 | 3.60
>  64 | 0.70
>
> Although I understand that the total load will increase a little bit
> for smaller packets due to increased overhead (headers) as seen from
> spp=1024 to spp=512, I find it confusing that so many packets are
> dropped for spp <= 256.
>
> Total goodput should be 200 MSps * 4 byte per sample (sc16) = 800 MBps
> = 6.40 Gbps.
>
> Is RFNoC somehow limited to a certain number of packets per second
> (regardless of their size)?
> Could this be resolved by increasing the STR_SINK_FIFOSIZE noc_shell
> parameter of any blocks connected to the RFNoC Radio?
>
> I would like to use spp=64 because that is the size of the RFNoC FFT I
> want to use. I am using UHD 4.0.0.rfnoc-devel-409-gec9138eb.
>
> Any help or ideas appreciated!
>
> Best,
> Sebastian
>
> This is almost certainly an interrupt-rate issue having to do with your
 ethernet controller, and nothing to do with RFNoC, per se.

 If you're on Linux, try:

 ethtool --coalesce   adaptive-rx on
 ethtool --coalesce  adaptive-tx on

>>>
>>> Thanks Marcus for your quick response. Unfortunately, that did not help.
>>> Also, `ethtool -c enp1s0f0` still reports "Adaptive RX: off TX: off"
>>> afterwards. I also tried changing `rx-usecs` which reported correctly but
>>> did not help either. I am using Intel 82599ES 10-Gigabit SFI/SFP+
>>> controller with the driver ixgbe (version: 5.1.0-k) on Ubuntu 16.04.
>>>
>>> Do you know anything else I could try?
>>>
>>> Thanks,
>>> Sebastian
>>>
>> The basic problem is that in order to achieve good performance at
>> very-high sample-rates, jumbo-frames are required, and using a very small
>> SPP implies
>>very small frames, which necessarily leads to poor ethernet
>> performance.
>>
>> Do you actually need the FFT results to appear at the host at "real-time"
>> rates, or can you do an integrate-and-dump within RFNoC, to reduce host side
>>traffic?
>>
>
> Yes, I need all the samples. Since it will be a full receiver
> implementation in RFNoC the output to the host will be much less than 6.40
> Gbps but still a decent amount and definitely more than the 0.7 Gbps I was
> able to achieve with spp=64.
>
> Do you think that it would suffice to change the packet size at my last
> RFNoC block before the host? I will try out the already available
> packet_resizer block tomorrow.
>
> So the question would be if RFNoC can handle passing packets with spp=64
> at 200 MSps between RFNoC blocks. If this is likely to be a problem, I
> could try wrapping all my HDL code into one RFNoC block and handle the
> packet resizing at input and output of this block. However, I would like to
> avoid this step if possible.
>
> Thanks for your help!
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinf