Marcus,

To clarify the purpose of this question: if we get X310, will we have ability (maybe by modifying firmware) to have larger transfer buffer, and how much can be increase in size comparing to X300?

I didn't realize that X3X0 has 1GB DRAM (Shown on the diagram in  http://www.ettus.com/content/files/X300_X310_Spec_Sheet.pdf ). Is this the DRAM that you mentioned? Can you please summarize all the memory in both units?

E.g., is this correct: both X300 & X310 have 1 GB DRAM, and SRAM size differs according the FPGA model (16,020 Kb and 28,620 Kb as specified here: http://www.ettus.com/product/details/X310-KIT )?

Theoretically, if we alter FPGA firmware, can we increase xfer buffers, or their sizes are hardware defined? Didn't find the info about those two firmware versions you spoke about - where to read on this, or what is the difference btw them?

Thanks!
Vladimir

identical.

they are absolutely identical (I'd have to read the FPGA source code
[1]), yes, but it's not large enough to buffer seconds of sample
data -- that would inherently lead to a lot of latency, and in
almost all applications, that would be unwanted. We actually do have
two different stock images for the FPGA, one using only SRAM (HGS),
and one using DRAM (XGS); the first is the default, and most
customers use it.

packet/burst-based, so there's some kind of inevitable buffering;
however, the USRP keeps it's own reference oscillator-disciplined
time, and gives you timestamps with the RX samples, as well as
allowing you to specify the exact time when a sample should be sent,
or a command (such as tuning, setting gain) should be exectuted.
That's why in many cases, the interface latency doesn't matter at
all -- you just make sure that the first bunch of samples of your
transmission burst is sent "early enough" to the USRP, and add a
timespec telling the USRP to hold these samples.

interface on the edge of a PPS (pulse-per-second) signal (doesn't
really need to be a pulse per second if you really just want to set
the device time once -- a pull-up switch does work ;) ), or without
external time reference by just instructing the X3x0 to set a new
time in its timing registers.

  USRP-users wrote:

  host, or its used only for signal processing algorithms? May be
  this is another question, but does X300 do any IO buffering at
  all, to provide accurate clocking of the samples when interfacing
  e.g. with ethernet? Is there some buffer there and how big is it?

    Marcus Müller via USRP-users <usrp-users@lists.ettus.com> :

            is that the X310 has the bigger FPGA, which only makes a
            difference if you want to do custom processing on it --
            for example, building a largish RF NoC application.
            Otherwise, X300 and X310 are absolutely identical.

              it's very helpful for us! Looking at all this, seems
              that we could start from 10 GBE link and then see if
              we need more latency or whatever else to try PCIe.

              has been discussed, how big is the difference btw X300
              and X310? One of the diffs is that X310 has more
              memory - ~3.5 MB if I don't mistake, comparing to 2 MB
              in X300. Does it use this memory to do some sort of
              buffering when transferring data to/from host? Will it
              help to withstand any short hitches/delays that happen
              during streaming? For now, it's the only reason I
              could imagine to prefer X310 from this point of view.

                24 июля 2015, 1:22 +02:00 от Marcus Müller via
                USRP-users <usrp-users@lists.ettus.com> :

                        question, I think Rob did an excellent job
                        of providing the info you've asked for;
                        thank you!

                        wrote:

                        or a pair of transceivers for whatever
                        electrical or optical medium you plan to
                        use.

                        yes, PCIe is not the bus of choice for
                        maximum throughput. In fact, most PCIe
                        10Gigabit network adapters, and especially
                        the Intel devices, have drivers that are
                        very good of distributing work across
                        multiple CPU cores and reducing interrupt
                        pressure -- it's in fact progressively hard
                        for some customers to get high rates
                        (>ca. 150MS/s total) with the PCIe
                        interface, mainly because the NI driver for
                        compatibility reasons is single threaded,
                        and a single core can only spin so fast.

                        with the NI side of PCIe / PXI backend
                        equipment. Generally, you only need to use either 10GE  or PCIe. Use PCIe if you want
                        to combine things into large
                        LabVIEW-commanded clusters of USRPs  [1], or
                        if you know that you need the possibility to
                        reduce USRP-host latency of the expense of
                        more CPU consumption. For the general user,
                        I recommend 10GE.

                        can only use integer factors of the master
                        clock rate as sampling rates. For the
                        default Master Clock Rate of 200MHz, these
                        are 200MS/s, 100MS/s, (66.666..MS/s),
                        50MS/s, ..., but there is also the 120MS/s
                        master clock rate, which is predominantly
                        used by LabView, and can hence be used to
                        get sampling rates of 120, 60, (40), 30
                        MS/s. Also, we have an cellular-friendly
                        184.32 MHz master clock rate. Notice that I
                        put some potential sampling rates into
                        parentheses; these are odd decimations of
                        the master clock rate, which hence don't
                        exhibit the same quality of
                        flatness/anti-aliasing as the even
                        decimations.

                        the "much better" part. "much better"
                        depends very much on your needs; if you
                        couldn't use e.g. the N210 for its frequency
                        offset or drift being much too large, then
                        you'll want to use an external reference
                        here, too. However, most customers are quite
                        happy with the oscillators we have on board
                        -- simply because frequency offset is a
                        given fact in digital communications, and
                        typically, the oscillator outperforms things
                        like mobile terminals very significantly.
                        This doesn't necessary apply to things like
                        high-performance interferometry, or very
                        accurate signal detection.

                        of the cells they supply, so you don't have
                        to worry. The oscillators really aren't that
                        bad -- they just aren't perfect.

                        daughterboard each, allowing you to do 2x2
                        MIMO.

                        answers:

                        up to roughly 20dBm; for details, see
                        [2]; safe input range is -infty to -15dBm.

                        privileges and runs completely in userland.
                        Only the network card or PCIe bridge card
                        have kernel drivers.

                        definitely is, as Rob mentioned, that it's
                        in no way "simple" to save 2x 100MS/s to
                        disk. There's been (and will always be, and
                        that's a good and just thing) long
                        discussions on the needs, feasibility and
                        example implementation support of sustaining
                        such hard drive write rates.

                        short integer fixed point complex recording:

                        2numbers/complex *1complex/S * 100MS/s
                        =3.2Gb/s for a single channel!

                        rates, meaning, that unless you can come up
                        with ridiculous amount of write buffering,
                        the hard drive minimum write rate must be
                        above this value, and that doesn't even
                        account for the fact that data is typically
                        written to file systems that add even
                        further overhead and latency. Now, I just
                        came up with this less than reliable
                        source[2]; bad news is that the fastest hdd
                        has an average write rate of 193MB/s
                        (ca 8*200Mb/s = 1.6Gb/s) according to their
                        benchmark -- meaning that the minimum rate
                        will be significantly lower. So even a raid
                        of 2 or 3 hard drives will not be
                        sufficient, and of four only if there
                        weren't such things as seek latency. In
                        short: Writing that bulk of data to disk in
                        realtime isn't easy anymore; but RAM disks
                        work fine, so be sure to have enough RAM.

USRP-users mailing listUSRP-users@lists.ettus.com

USRP-users mailing listUSRP-users@lists.ettus.com

Vladimir,
both X300 and X310 using the factory FPGA images offer approximately 520K Bytes of SRAM FIFO that buffers Tx data before transmission. This buffer decouples the host and transport with it's inherent scheduling latency and jitter from the hard real-time nature of the DAC's consuming data. That amount is empirically enough to run practical applications at the highest sampling rates possible on the X300, clearly at much lower sampling rates it's overkill. This is actually an easily altered parameter during the build process, but typical users would not alter it, there is very little motivation. Very few applications can make practical use of over large FIFO's for Tx because typical radio's do not know in advance when and what they will be transmitting.
We have a build option for the FPGA that uses DRAM instead of SRAM to build the large buffers but it's not currently able to reliably sustain throughput in the corner cases that can occur at the highest MIMO sample rates and is thus still the subject of development effort. The DRAM is far larger than any practical Tx FIFO's would need to be and it is included for the flexibility of FPGA developers who may use it for all sorts of things. Expect to see some RFNoC blocks using it for example.

-Ian

On Jul 24, 2015, at 7:05 AM, Vladimir via USRP-users usrp-users@lists.ettus.com wrote:

Ian,

Thank you for the explanation! And what about Rx - is it also buffered similarly? We are mainly concerned about Rx buffering, since it probably can compensate some hitches in ethernet/pcie interface. The question is: does X310 have more memory that we could use to extend Rx buffer? How much is this difference, comparing to X300? We have to select one of them and need to estimate, how big is the difference from this point.

Vladimir

identical.

they are absolutely identical (I'd have to read the FPGA source code
[1]), yes, but it's not large enough to buffer seconds of sample
data -- that would inherently lead to a lot of latency, and in
almost all applications, that would be unwanted. We actually do have
two different stock images for the FPGA, one using only SRAM (HGS),
and one using DRAM (XGS); the first is the default, and most
customers use it.

packet/burst-based, so there's some kind of inevitable buffering;
however, the USRP keeps it's own reference oscillator-disciplined
time, and gives you timestamps with the RX samples, as well as
allowing you to specify the exact time when a sample should be sent,
or a command (such as tuning, setting gain) should be exectuted.
That's why in many cases, the interface latency doesn't matter at
all -- you just make sure that the first bunch of samples of your
transmission burst is sent "early enough" to the USRP, and add a
timespec telling the USRP to hold these samples.

interface on the edge of a PPS (pulse-per-second) signal (doesn't
really need to be a pulse per second if you really just want to set
the device time once -- a pull-up switch does work ;) ), or without
external time reference by just instructing the X3x0 to set a new
time in its timing registers.

  USRP-users wrote:

  host, or its used only for signal processing algorithms? May be
  this is another question, but does X300 do any IO buffering at
  all, to provide accurate clocking of the samples when interfacing
  e.g. with ethernet? Is there some buffer there and how big is it?

    Marcus Müller via USRP-users <usrp-users@lists.ettus.com> :

            is that the X310 has the bigger FPGA, which only makes a
            difference if you want to do custom processing on it --
            for example, building a largish RF NoC application.
            Otherwise, X300 and X310 are absolutely identical.

              it's very helpful for us! Looking at all this, seems
              that we could start from 10 GBE link and then see if
              we need more latency or whatever else to try PCIe.

              has been discussed, how big is the difference btw X300
              and X310? One of the diffs is that X310 has more
              memory - ~3.5 MB if I don't mistake, comparing to 2 MB
              in X300. Does it use this memory to do some sort of
              buffering when transferring data to/from host? Will it
              help to withstand any short hitches/delays that happen
              during streaming? For now, it's the only reason I
              could imagine to prefer X310 from this point of view.

                24 июля 2015, 1:22 +02:00 от Marcus Müller via
                USRP-users <usrp-users@lists.ettus.com> :

                        question, I think Rob did an excellent job
                        of providing the info you've asked for;
                        thank you!

                        wrote:

                        or a pair of transceivers for whatever
                        electrical or optical medium you plan to
                        use.

                        yes, PCIe is not the bus of choice for
                        maximum throughput. In fact, most PCIe
                        10Gigabit network adapters, and especially
                        the Intel devices, have drivers that are
                        very good of distributing work across
                        multiple CPU cores and reducing interrupt
                        pressure -- it's in fact progressively hard
                        for some customers to get high rates
                        (>ca. 150MS/s total) with the PCIe
                        interface, mainly because the NI driver for
                        compatibility reasons is single threaded,
                        and a single core can only spin so fast.

                        with the NI side of PCIe / PXI backend
                        equipment. Generally, you only need to use either 10GE  or PCIe. Use PCIe if you want
                        to combine things into large
                        LabVIEW-commanded clusters of USRPs  [1], or
                        if you know that you need the possibility to
                        reduce USRP-host latency of the expense of
                        more CPU consumption. For the general user,
                        I recommend 10GE.

                        can only use integer factors of the master
                        clock rate as sampling rates. For the
                        default Master Clock Rate of 200MHz, these
                        are 200MS/s, 100MS/s, (66.666..MS/s),
                        50MS/s, ..., but there is also the 120MS/s
                        master clock rate, which is predominantly
                        used by LabView, and can hence be used to
                        get sampling rates of 120, 60, (40), 30
                        MS/s. Also, we have an cellular-friendly
                        184.32 MHz master clock rate. Notice that I
                        put some potential sampling rates into
                        parentheses; these are odd decimations of
                        the master clock rate, which hence don't
                        exhibit the same quality of
                        flatness/anti-aliasing as the even
                        decimations.

                        the "much better" part. "much better"
                        depends very much on your needs; if you
                        couldn't use e.g. the N210 for its frequency
                        offset or drift being much too large, then
                        you'll want to use an external reference
                        here, too. However, most customers are quite
                        happy with the oscillators we have on board
                        -- simply because frequency offset is a
                        given fact in digital communications, and
                        typically, the oscillator outperforms things
                        like mobile terminals very significantly.
                        This doesn't necessary apply to things like
                        high-performance interferometry, or very
                        accurate signal detection.

                        of the cells they supply, so you don't have
                        to worry. The oscillators really aren't that
                        bad -- they just aren't perfect.

                        daughterboard each, allowing you to do 2x2
                        MIMO.

                        answers:

                        up to roughly 20dBm; for details, see
                        [2]; safe input range is -infty to -15dBm.

                        privileges and runs completely in userland.
                        Only the network card or PCIe bridge card
                        have kernel drivers.

                        definitely is, as Rob mentioned, that it's
                        in no way "simple" to save 2x 100MS/s to
                        disk. There's been (and will always be, and
                        that's a good and just thing) long
                        discussions on the needs, feasibility and
                        example implementation support of sustaining
                        such hard drive write rates.

                        short integer fixed point complex recording:

                        2numbers/complex *1complex/S * 100MS/s
                        =3.2Gb/s for a single channel!

                        rates, meaning, that unless you can come up
                        with ridiculous amount of write buffering,
                        the hard drive minimum write rate must be
                        above this value, and that doesn't even
                        account for the fact that data is typically
                        written to file systems that add even
                        further overhead and latency. Now, I just
                        came up with this less than reliable
                        source[2]; bad news is that the fastest hdd
                        has an average write rate of 193MB/s
                        (ca 8*200Mb/s = 1.6Gb/s) according to their
                        benchmark -- meaning that the minimum rate
                        will be significantly lower. So even a raid
                        of 2 or 3 hard drives will not be
                        sufficient, and of four only if there
                        weren't such things as seek latency. In
                        short: Writing that bulk of data to disk in
                        realtime isn't easy anymore; but RAM disks
                        work fine, so be sure to have enough RAM.

USRP-users mailing listUSRP-users@lists.ettus.com

USRP-users mailing listUSRP-users@lists.ettus.com

Vladimir,

Quite the same for the RX. Again, as soon as start implementing your own stuff on the FPGA, there's basically no limit on how you distribute usage of the DDR RAM. There is boo difference between x310 and x300.

Best regards,
Marcus

Am 24. Juli 2015 18:29:27 MESZ, schrieb Vladimir via USRP-users usrp-users@lists.ettus.com:

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Vladimir,
Rx is much easier than Tx. The thing to realize is that all modern ethernet is full-duplex. Thus X300 only has to arbitrate amongst its own traffic sources. We will occasionally hold up the Rx sample packets so we can send a control or status packet back to the host and so there is some elasticity in the pipeline, but there is only a fraction of the buffering thats needed for Tx. Rx data accumulates in the Hosts RAM buffers waiting for the application to consume it, not on the USRP.

-Ian

On Jul 24, 2015, at 9:29 AM, Vladimir via USRP-users usrp-users@lists.ettus.com wrote:

Hi Vladimir,

Is the X300 connected directly to the host computer via the Ethernet cable?
And are you using Port 0 or Port 1 to attach the Ethernet cable on the X300?

-Trip

On Mon, Nov 9, 2015 at 11:13 AM, Vladimir via USRP-users <
usrp-users@lists.ettus.com> wrote:

Yes, directly to Port 0, and it does not seem to have any problems connecting. I could ping the device without a problem from the very beginning, it just reported version mismatch as usual, until I uploaded the right one for 3.009.001.

Vladimir

Hi Vladimir,

Do you still get the error if you specify the same input arguments as you
did in the first example?

uhd_usrp_probe.exe --args="type=x300,addr=192.168.10.2"

-Trip

On Mon, Nov 9, 2015 at 6:10 PM, Vladimir www2008_2@mail.ru wrote:

Hi Vladimir,

It could be the Ethernet controller or MTU setting.  Make sure your MTU is
set to 1500 (some 1 GbE controllers do not support jumbo frames), make sure
you have the latest driver for the Ethernet controller, and make sure the
controller is not the Intel 82579LM (it has know issues with dropping UDP
packets).  If all that looks good, use Wireshark to inspect the network
traffic and make sure you are seeing responses from 192.168.10.2:49153 to
the host when executing uhd_usrp_probe.exe.

Regards,
Michael

On Mon, Nov 9, 2015 at 5:31 PM, James Humphries via USRP-users <
usrp-users@lists.ettus.com> wrote: