[USRP-users] Hardware selection for X310-based system

Vladimir www2008_2 at mail.ru
Fri Jul 24 07:19:14 EDT 2015


Yes, I understand this, but does it affect the connectivity with 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?


>Пятница, 24 июля 2015, 13:09 +02:00 от Marcus Müller via USRP-users <usrp-users at lists.ettus.com>:
>The difference 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.
>Best regards,
>On 24.07.2015 13:05, Vladimir via
      USRP-users wrote:
>>Hi guys,
>>I wish to thank all of you for valuable information, 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.
>>I forgot one question yesterday. From the point that 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.
>>Again, thank you very much for the info!
>>>Пятница, 24 июля 2015, 1:22 +02:00 от
        Marcus Müller via USRP-users <usrp-users at lists.ettus.com> :
>>>Hi Vladimir,
>>>although he claimed not to answer your question, I think
                Rob did an excellent job of providing the info you've
                asked for; thank you!
>>>Hence, I'll keep this as short as possible
>>>On 23.07.2015 22:31, Vladimir via USRP-users wrote:
>>>>1. We already have an Intel X520-DA2 board which Ettus recommends for 10GBE input. Would it suffice to order just 783343-01 (10 Gb SFP+ ETHERNET CABLE, 1M) to X310 kit to get complete setup to be able to stream data into/from PC? That, or any direct attach SFP+ 10GE cable, or a pair of
                transceivers for whatever electrical or optical medium
                you plan to use.
>>>>2. From what I read earlier here and saw at Ettus website, I understand that PCI-Express Connectivity Kit (PCIe – Desktop) is NI PCIe-8371 board with the cord. NI states its speed to be 798 MB/s. But to stream 100 MS/s we need 800 MB/s. Is their number - 798 - approximate (which would look kind of strange for me given its precision :)) and this won't in practice lead to speed problems, or do they actually mean 798 MiB/s, or some other explanation? Could anyone shed some light on this? I must admit that this is news to me. But 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.
>>>>3. Would it make sense to look at the NI-recommended alternative - 8381 board? Given that the price difference on NI site for 8371 and 8381 is just $50, is it a good idea to go with 8381 to be sure it definitely won't be a bottleneck? Or it was not tested with X310 and we might encounter some compatibility issues, or any other reasons against it? If it was tested, can we order it from Ettus instead of 8371 at comparable price? I must admit I'm really not overly familiar 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.
>>>>4. Do I get it right that if we encounter problems on 100 MS/s, the next sampling rate we can use would be 50 MS/s, as we must use integer decimation values from the max one? And in this case we'll get 100 MHz bandwidth and limit X310 potential of 120 MHz. Am I correct here? You're quite right. So the point is that you 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
>>>>5. Am I coerrect that the frequency accuracy of stock X310 oscillator is much better than that of previous models, so we don't need external clock if we don't plan to sync several devices, work at large distance, etc? Uh, to be honest, I'm not quite sure about 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.
>>>>It won't be used for any 'real-world' cases like network deployment etc, - still, speaking about GSM/UMTS lab experiments (like connecting one-two MS in the room), may we need additional clock source? No. Base Stations/eNodeBs define the clock of the cells
                they supply, so you don't have to worry. The oscillators
                really aren't that bad -- they just aren't perfect.
>>>>Am I missing any critical parts to build up the working SDR set? Well, you mentioned using UBX-160, but you can use
                both daughterboard slots with one daughterboard each,
                allowing you to do 2x2 MIMO.
>>>A few typical frequently answered questions' answers:
>>>* all RF interfaces are 50 Ohm matched
>>>* the output of the UBX daughterboard can go up to roughly 20dBm; for details, see [2]; safe input range is -infty
                to -15dBm.
>>>* UHD itself doesn't need any special privileges and
                runs completely in userland. Only the network card or
                PCIe bridge card have kernel drivers.
>>>* Ettus support will be on your side.
>>>>I would also like to hear from people who tried to get about 100-120 MHz RX-TX bandwidth from X3X0, e.g. just simply streaming at 100 MS/s to/from disk and doing processing offline later  - which is the most stable and reliable way to do it - 10GBE or PCIe? In my experience: 10GE. The problem here 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.
>>>A quick calculation shows that, for 16bit short integer
                fixed point complex recording:
>>>datarate(100MS/s) = 16bit/number * 2numbers/complex
                *1complex/S * 100MS/s =3.2Gb/s for a single channel!
>>>Now, you need to guarantee these 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.
>>>Best regards,
>>>Marcus Müller
>>>[1] http://www.ni.com/white-paper/52382/en/
>>>[2] http://files.ettus.com/performance_data/ubx/UBX-without-UHD-corrections.pdf
>>>[3]  http://hdd.userbenchmark.com/
>>>USRP-users mailing list
>>>USRP-users at lists.ettus.com
USRP-users mailing listUSRP-users at lists.ettus.com
>USRP-users mailing list
>USRP-users at lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150724/0f6ad0b9/attachment-0002.html>

More information about the USRP-users mailing list