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

Marcus Müller marcus.mueller at ettus.com
Thu Jul 23 19:22:52 EDT 2015

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 decimations.
> 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

[3] http://hdd.userbenchmark.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150724/88043ebb/attachment-0002.html>

More information about the USRP-users mailing list