The LimeSDR-mini only has 549 Kb of RAM in the FPGA whereas the LimeSDR-USB has 256MiB of DDR2 SDRAM which is roughly 4000x the space that could be used for buffering as well as 1134 Kbits of RAM in its FPGA.
I think that there may also be more efficient bit-packing in terms of USB bandwidth but less efficient in that it generates more heat that must be dissipated used by the LimeSDR-USB. And so to reduce the cooling requirements for a much smaller board I think that a simpler bit-packing was used, but I still need to fully read through the gateware doodling patterns of bits with a pencil and paper to verify. But speed reading it I think that the mini packs four 12-bit samples (or two pairs of 12-bit IQ samples) into each 64-bit word, for transfers across the USB bus. This would also reduces the processing overhead of multi-word bit manipulation on the PC before samples can actually be used for anything, so it has upsides. Also since the LimeSDR-mini was designed to have a maximum sample rate of 30.72 MSPS and does not need to support MIMO, it should not need to go to such extremes of tight bit-packing to transfer enough samples across the USB bus. There is also the possibility that there may not even be enough free Logic Elements in the mini’s FPGA to implement the more complex bit-packing anyhow, irregardless of the extra cooling requirements.
At 40 MSps and 12-bit sample format, data rate should be a bit higher than 120 MB/s (40*3 + some overhead) so it does not look that a lot of packets are being lost.
You can check ‘Freeze FFT’ to disable FFT calculation and reduce load if you are only interested in data rate.
I am not sure about buffer sizes in FPGA but I think they are something like 16-20KB. I think samples are being dropped when FTDI chip does not take them from FPGA fast enough ( either PC is not requesting it or there are to many resends or some other reason).
Also, I have checked LimeSDR-Mini on my machine (Ubuntu 16.04, i7-3770) and using RX only in LimeSuiteGUI (FFTviewer) I am able to get 56 MSps (reports 168.69 MB/s data rate) without packet drops
Unfortunatelly not all people give complete information about used hardware. Ok, you are using Linux and fast i7 CPU but without used USB host controller we don’t have complete picture. Cypress in FX3 performance tests claims that Intel USB 3.0 eXtensible Host Controller gives from 20% to 50% better results then competitors chipsets. Personaly I’m very happy with Mini performance at 30MS/s and my post was just responce to reported problems at much lower sample rates. My PC is AMD Ryzen 5 1500X and Asrock AM4 AB350 motherboard, Win 10 64bit Home.
BTW to my disappointment AMD USB 3.0 controller on Linux works pretty slow.
So we need to know your hardware, not just OS and CPU. As the Lime devices also target Windows maybe you could repeat the same tests on your hardware with Windows to help the many Lime Mini owners?
When calling LMS_RecvStream what is the sample count and other values you supply?
Better would be for IgnasJ to use a computer Ubuntu or Windows) with different USB chipset where the high throughput with the Mini can’t be sustained, then use this machine to help diagnose the issue many of us have. I have two very fine PCs here, I can help with any diagnostics.
It’s not a lot of packets at first, 6-20ish… but if you load down the CPU to above 40% using something like prime95, then it jumps into the thousands, even though there’s still plenty of CPU to deal with it…
I tried it on Windows 10 and it looks a bit worse. I still get some dropped packets at 40 MSps and 30 MSps is without dropped packets (did not check in between). However, dropped packet count is not high until set sample rate t oabout ~60Msps. At 40 MSps there is on average about 5 dropped packets per second, at 50 MSps - ~20 packets, at 55 MSps - ~40 packets and at 60 MSps it jupms to ~1500 dropped packets per second.
Using 60 MSps on Ubuntu also gives similar dropped packets results, so it might be because of some throughput limitations. Dropped packets bellow 55 MSps looks like thread scheduling or system load issues.
Default settings in LimeSuiteGUI are:
read sample count in LMS_RecvStream() is 16384 (equal to FFT size setting in FFTviewer)
fifo size: 51216384 (512 FFT size)
throughputVsLatency: 0.8
dataFmt: LMS_FMT_I12
Thanks - the values are interesting, I will try them. Taming the Mini isn’t easy, I’m trying to get the radio to stream properly - will be posting about this soon.
We’re trying to do less than that, around 20MSPS at 12 bit. All in windows 10. If you run the little limetest.exe posted above, it will show dropped packets at 19.2MSPS, and while that program is running, do something to load the CPU, like run a few instances of prime95. I think you’re on the right track as it does look like a thread scheduling issue, as it starts dropping massive numbers of packets at a relatively light CPU load.
The question is why? It’s not like the USB bus is being saturated by CPU threads. The hardware shouldn’t be dropping packets at that point, but it does certainly appear to be doing just that. The packets aren’t even making it to the USB port when the system is even slightly loaded.
We’ve done this test with the same/similar results on everything from an i5-8500 to an i7-8700, and an i9-9900k. All systems with PLENTY of resources. Same effect on Asus, Asrock, MSI, Gigabyte and intel reference design motherboards. But, using the LimeSDR USB shows absolutely NONE of these problems under the same load testing.
It has to be somewhere in the gateware that these packets get dropped, or so it’d appear…
Ok, I have just tried your LimeTest.exe. I see no problems running without additional system load.
Running prime95 with default settings does not seem to cause issues either:
I can get large amounts of dropped packets if I increase prime95 worker threads priority (Test->Worker Windows->Priority) to 8 (default is 1).
From my testing so far, it looks like something (that likely has high priority) on your system prevents USB transfers from being handled fast enough.
Well, obviously FX3 chip in LimeSDR-USB has larger endpoint buffers and provides higher throughput than FT601 in LimeSDR-Mini. That is one of the reasons why Mini is rated for lower sample rates. Also, they use different drivers. However you should be able to get 30 MSps with Mini, while higher sample rates may be hit or miss.
Yes, they are most likely dropped in gateware because USB chip is not taking them (because PC is not taking them from USB chip).
Might it be possible to solve this with a multi-prong approach?
For example, packing five 12-bit samples into each 64-bit word would not only decrease the data rate by 20%, it would also increase the available buffer by 25%. Perhaps this alone would be enough to keep samples from being dropped at the claimed-capable rate of 30 MSps?
And if that’s not enough, is it possible to use a part of the FPGA as more buffer space? How much (if any) remains?
In our particular application, we don’t need to transmit at all, it’s receive only, that would in theory make it possible, right?
Also, how is it that’s it’s working this well on IgnasJ’s system, on Windows, yet not on any of my multiple systems? Are there different hardware revisions of the Mini? Am I doing something else wrong? How do I figure out what?
bump Any of the Lime guys chime in on this? I’m stuck at this point of actually using this piece of hardware. I’m having troubles under even moderate CPU load (under 50%) of an i7 asking for 12Msps without dropped packets.
As to threads that have a higher priority, our application is the only thing running besides windows crapware in the background, which thanks to microsoft, you can’t turn off 80% of it.
There is a common problem with some machines on Windows 10 with USB 3 and other devices. Try turning off Fast Startup in power option, choose what power buttons do and also set to high performance.
