No, Rockchip RK3588S is even more powerful than RK3568. These puppies have absolutely no problem throwing a gigabyte per second around, continously.
I didn't tried that RK3588S, but a much powerful desktop i3 has performance issues even with 20 MS/s.
I think you have way too much faith in Intel.
if you're planning a real usage through GMII or USB interface, it will starts packet drops at much slower data flow.
Sigh. The USB 3 numbers are from real benchmarks.
Yes, Raspberry Pi's USB implementation is utter shite, because it can drop packets silently.
Also, Windows is not useful for this kind of stuff; you don't run a GUI on a high-performance measurement instrument. The amount of resources Windows needs is not related to how much resources the same task in e.g. Linux needs, really.
UDP/IP payload bandwidth at optimal conditions using gigabit is about 120 MBytes/second, and Odroids can sustain about 90% of that, or 110 MBytes/second, as one can easily benchmark (including using simple C programs). With a direct link, increasing MTU will give slightly better performance.
Radxa Rock5B, for example, has a 2.5Gbit Ethernet (RTL8125B), with practical bandwidth around 2.35 Gbit/s according to
iperf benchmarking, so using UDP/IP over a dedicated link (no collisions), you should be able to get 2 Gbit/s or 250 Mbytes/s transfer rate in practice – which is two thirds more than you actually need.
And note that there is required continuous transfer in realtime, not a signle burst transfer.
I
know. One of my hobbies is interfacing to various sensory things using Teensy 4, a $24 dev board for NXP i.MX RT1062. Unlike many other microcontrollers, this one has native USB 2.0
high speed interface (two, actually), and even a trivial USB Serial example can reach 200+ Mbit/s (or 25 Mbytes/s)
payload in one direction. I test this with a Xorshift64 PRNG, generating the data (it runs at 600 MHz) on both the Teensy and my host computer, so I even verify the data is correct. I measure the interval between received chunks (using wall clock, or POSIX CLOCK_REALTIME in Linux), and update min, max, avg, and stddev (median for limited runs). Then, I run it for a few hours to verify this can be
sustained.
To get closer to the theoretical maximum, I need to use bulk transfers, but as that rate is more than my sensor and small display things need, I haven't bothered even testing the maximum.
I've also done server-side development for years, so I know what bandwidth, PPS, latency, and other related terms
actually mean.
What I don't know, is the electronics side. I'm a hobbyist newbie when it comes to electronics, especially things like how to implement proper LVDS (or MIPI CSI) interfaces at 1.2 Gbit/s bandwidth.
You need large buffers, preferably mostly continuous ones, filled/drained via DMA or a dedicated CPU, to reach 2+ Gbits/s throughput.
The memory bandwidth is about 6 Gbytes/sec ("48 Gbit/s") on Odroid-M1 (
report), more on Rock5B and Orange Pi 5.
Storage tends to be quite optimized in Linux, so no problem there. The main problem is obtaining the ADC data. You will not achieve anywhere near the necessary bandwidth using GPIO pins; you'll need a native interface with DMA and sufficient bandwidth to do so.
In the aforementioned SBCs –– unlike e.g. Raspberry Pi's –– the storage buses (SATA and PCIe) are separate from the USB 3. They are peripherals integrated to the SoC, with DMA access to the SoC memory. While I haven't verified it, USB3 should easily exceed the needed bandwidth, if you had an USB 3 ADC or DAQ. Both RK3588 and RK3568 MIPI CSI can do 2.5 Gbits/sec per lane, and the boards expose either two or four lanes, so MIPI CSI bandwidth would not be an issue if you can just get the ADC to talk MIPI CSI (assuming a DIY frontend-ADC-FPGA-MIPI solution).
I wish I had an Odroid-M1, Rock5B, or Orange Pi 5, because then I could actually easily verify this, simply by connecting USB3 to a JMS567-SATA bridge and to a fast SATA drive, and check the sustained transfer rates to/from a Samsung PCIe M.2 (or other similar SSD with sufficiently high bandwidth on PCIe 3.0).
I'm very sure the result is well over 150 Mbytes/second, probably twice that (unless limited by the SATA drive), based on my experience with other SBCs.
It is very much equivalent to using USB 3 bulk transfers to an userspace process, and that process storing it to the PCIe M.2 (or vice versa).
I'm sure [odroid-m1] cannot handle even continuous gigabit data flow from Ethernet GMII interface. Just because much more powerful desktop PC cannot do it well without server ethernet adapter with hardware acceleration.
You're utterly, utterly wrong. Desktop PCs, especially those running Windows, aren't a good benchmark.
Look at the
Rock5B iperf benchmark here. This is just a short run, over 27 seconds, with at least 280 megabytes transferred each second (except the initial second). I prefer at least 15-20 minute runs, myself, but there is no reason to think this cannot be sustained.
Even old
Odroid XU4 can sustain 225 Mbytes/sec over USB3 using JMS578 USB-to-SATA bridge and Samsung SSD 850 PRO 256GB. That is 1.8 Gbits/s, well over the 1.5 Gbits/s you need. (I have the Odroid HC1 model, with the JMS578 bridge on board; on most SATA SSDs I have, the SSD itself is the bottleneck.)