To expand on #2, the TX is limited by the 10 GbE link and the DRAM bandwidth. The 10 GbE link limitation is resolved by using both SFP+ ports as 10 GbE ports. The DRAM limitation is not so easy to overcome. The DRAM bandwidth is ~600 Msps, but it is used as a FIFO, so the bandwidth is cut in half to ~300 Msps. That bandwidth is shared by all TX channels, which is the true limitation of the TX rate. If a custom RFNoC replay block is created in place of the DMA FIFO, the full 200 Msps bandwidth per channel is available.
Regarding #3, there is an example RFNoC replay block in the works. I cannot say exactly when it will be available, but it will probably be fairly soon. I have been told a month or so. Regards, Michael On Tue, Jul 31, 2018 at 7:41 AM, Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Farnaz, > Regarding #1, the USRP can be either Tx, Rx, or both, but it does not > affect maximum streaming rates. The 10Gbe link is bi-directional and can > handle a maximum of 300 MS/s on a single link in both directions. You can > use both links such that you can receive both channels of the X310 at 200 > MS/s. > > Regarding #2, yes. The USRP itself perhaps can handle the 200 MS/s per > channel on transmit, but the PC just can't keep the streaming at that rate > without hiccups. The best you can get is 100 MS/s per channel on Tx. > > Regarding 3, not sure. > > Rob > > On Tue, Jul 31, 2018 at 10:34 AM Farnaz Chamanzadeh <farnaz.c...@gmail.com> > wrote: > >> Dear Rob, >> >> 1. Can you explain if the USRP may be configured only in receive/transmit >> mode or is it also possible to configure in a single mode (a pure >> transmitter or a pure receiver) using both optical interfaces for the task? >> >> 2. In the first remark in your email, you mentioned that the >> host-to-USRP streaming does not work at 200 MS/s for the transmit case. >> Does it mean that in the USRP-to-host mode it supports 200MS/s per >> channel in receiving mode while the host to USRP supports only 100MS/s >> per channel? >> >> 3. About storing the samples on the USRP, does anyone know that if Ettus >> has any plans to add this capability to the USRPs? >> >> >> Best, >> Farnaz >> >> On Mon, Jul 30, 2018 at 6:27 PM, Jason Matusiak < >> ja...@gardettoengineering.com> wrote: >> >>> I've actually done this with success, unfortunately, I am not allowed to >>> share it :(. It wasn't too hard, I used a core in the block to hold the >>> data, and then I just repeated it when I sent it out over and over. >>> >>> The catch was that there was a little bit of an issue within rfnoc at >>> the time (you can see mailing lists conversations from back then in the >>> archives) that kept it from kicking off at startup (an enable switch worked >>> fine though). Jonathon P helped with a patch to get me going, but that >>> obviously has been mainlined by now since they have a siggen working (it >>> didn't exist yet when I did my block). The issue had something to do with >>> the block sending data before everything have been initialized and came up >>> properly. >>> >>> So it isn't too bad to create one. Good luck! >>> >>> >>> >>> --------- Original Message --------- >>> Subject: Re: [USRP-users] USRP X310 Remote Configuration >>> From: "Rob Kossler via USRP-users" <usrp-users@lists.ettus.com> >>> Date: 7/30/18 9:33 am >>> To: "Farnaz Chamanzadeh" <farnaz.c...@gmail.com> >>> Cc: "usrp-users" <usrp-users@lists.ettus.com> >>> >>> Perhaps look at the RFNoC siggen block. You will need to add some >>> component such as a block memory or fifo to store the samples on the fpga >>> and then you will need a way to populate the memory and then play it out >>> when desired. >>> >>> Rob >>> >>> On Mon, Jul 30, 2018 at 3:49 AM Farnaz Chamanzadeh < >>> farnaz.c...@gmail.com> wrote: >>> >>>> Dear Rob, >>>> Thanks for your helpful response. The reason that we need to use a >>>> switch is due to hour host hardware limits, which only have one 10GBE. >>>> About the second remark in your email, do you have an example or a >>>> reference where a similar case was implemented which we can use as a >>>> guideline for our implementation? >>>> >>>> Best regards, >>>> Farnaz >>>> >>>> On Thu, Jul 26, 2018 at 7:52 PM, Rob Kossler <rkoss...@nd.edu> wrote: >>>> >>>>> Hi Farnaz, >>>>> A couple of remarks and questions >>>>> - Remark 1: in order to get 200 MS/s transmit streaming, you will NEED >>>>> to have the samples on the USRP. The host-to-USRP streaming does not work >>>>> at 200 MS/s for the transmit case (unless something has recently changed). >>>>> The host-to-USRP max for transmit is 100 MS/s per channel >>>>> - Remark 2: that leads into your question about having the samples >>>>> stored on the USRP rather than streamed from host. This is not presently >>>>> a >>>>> capability, but can be added with some modest FPGA work. I have been >>>>> desiring such capability for a couple of years - I hope that Ettus adds >>>>> such capability in the future. >>>>> - Question 1: why do you plan to use a 10gbe switch with a single >>>>> connection to the host PC? Why not have multiple 10Gbe links at the PC >>>>> which connect to each USRP individually. A NIC such as Intel XL-710 >>>>> provides 4 10gbe links. >>>>> >>>>> Rob >>>>> >>>>> >>>>> On Thu, Jul 26, 2018 at 12:13 PM Farnaz Chamanzadeh via USRP-users < >>>>> usrp-users@lists.ettus.com> wrote: >>>>> >>>>>> Dears, >>>>>> >>>>>> To be more specific, we want to control multiple USRPs with one >>>>>> (remote) computer. We would like to stream known and periodic signal from >>>>>> each USRP. The sequence on each USRP is unique and is different from >>>>>> other >>>>>> USRPs. >>>>>> >>>>>> Since the samples from each USRP are known, it would be more >>>>>> convenient if we can generate the samples once and preferably store them >>>>>> locally on each USRP. In this configuration, we want to use the host >>>>>> computer to send control commands to the USRPs specifying when each of >>>>>> them >>>>>> must transmit its specific samples. The USRPs are assumed to be >>>>>> synchronized, so the control commands from the host will generate a TDMA >>>>>> scheme. Each USRP will start signal transmission upon receiving the >>>>>> control >>>>>> command from the host computer. I would like to know that: >>>>>> >>>>>> 1. Is it possible to store the samples on the USRPs? or should we >>>>>> stream the samples from the host computer to the USRPs for each >>>>>> transmission? >>>>>> 2. Can we use the full bandwidth and 200MS/s in this setup? >>>>>> 3. After knowing the answer to the previous question, I would like >>>>>> to know how we can implement it? do you happen to have a demo or an >>>>>> example >>>>>> that can guide us in this implementation? >>>>>> >>>>>> Best, >>>>>> Farnaz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jun 27, 2018 at 4:50 AM, Michael West <michael.w...@ettus.com >>>>>> > wrote: >>>>>> >>>>>>> Hi Farnaz, >>>>>>> >>>>>>> To clarify and expand on Marcus' comments, the answer is maybe. You >>>>>>> can do burst captures and transmissions at full rate and you can even >>>>>>> use >>>>>>> timed commands to synchronize them, but there are limitations. If you >>>>>>> can >>>>>>> describe in more detail what you want to do, we can more clearly tell >>>>>>> you >>>>>>> if it is possible. How many channels do you plan to do simultaneously? >>>>>>> How many 10 GbE connections between the host and switch? How many 10 >>>>>>> GbE >>>>>>> connections between each USRP and the switch? >>>>>>> >>>>>>> There is buffering of the TX samples on the X310 and it is >>>>>>> configurable. The current default is 32 MB. The DRAM is a total of 1 >>>>>>> GB, >>>>>>> and it can be divided up however necessary. >>>>>>> >>>>>>> Regards, >>>>>>> Michael >>>>>>> >>>>>>> On Mon, Jun 25, 2018 at 12:23 PM, Marcus Müller via USRP-users < >>>>>>> usrp-users@lists.ettus.com> wrote: >>>>>>> >>>>>>>> Dear Fernaz, >>>>>>>> >>>>>>>> you can't cheat 10Gig bandwidth! If you time-share any medium, then >>>>>>>> it's bandwidth must be shared. Since ethernet is de facto a >>>>>>>> timesharing >>>>>>>> thing, anyway, no, this won't work: >>>>>>>> Since you need to push through all the data through a single 10GigE >>>>>>>> connection, your 10 gigabits per second need to be divided along >>>>>>>> *all >>>>>>>> simultaneously operating* USRPs. So, if you have, say 10 USRPs, and >>>>>>>> all >>>>>>>> should be working at the same time, you've only got 1 gigabit per >>>>>>>> second per USRP, which limits you to about 25 MSample/s per USRP. >>>>>>>> It's >>>>>>>> really the same principle as a single internet access being shared >>>>>>>> by >>>>>>>> all people attached to the same router. >>>>>>>> >>>>>>>> Now, if these USRPs *don't* have to transmit all at the same time, >>>>>>>> then >>>>>>>> more is possible. >>>>>>>> >>>>>>>> > Also, does anyone know if it is possible to store the samples on >>>>>>>> the >>>>>>>> transmit USRPs? >>>>>>>> >>>>>>>> I'll go with a: no, at least probably not like you hope it is. Can >>>>>>>> you >>>>>>>> elaborate on your use case? Maybe we can help you if we better >>>>>>>> understand what you're trying to implement, from a bit of distance? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Marcus >>>>>>>> >>>>>>>> On Mon, 2018-06-25 at 20:32 +0200, Farnaz Chamanzadeh via USRP-users >>>>>>>> wrote: >>>>>>>> > Dear all, >>>>>>>> > >>>>>>>> > I want to connect multiple USRP X310 to one host PC and control >>>>>>>> them >>>>>>>> > all from that Pc, using one 10Gigabit Ethernet switch. My >>>>>>>> question >>>>>>>> > is that if it is possible to stream from each USRP in a different >>>>>>>> > time slot using the full bandwidth and 200MS/s in a setup similar >>>>>>>> to >>>>>>>> > the picture below? >>>>>>>> > >>>>>>>> > Also, does anyone know if it is possible to store the samples on >>>>>>>> the >>>>>>>> > transmit USRPs? >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > Best, >>>>>>>> > Farnaz >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > 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 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 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
