Fastest way to transfer to SSD

Questions and discussions about the Xillybus IP core and drivers

Fastest way to transfer to SSD

Postby Guest »

I would like to save data from a xillybus device onto an SSD.

If I cat from dev/xillybus > dev/ssd
then it doesn't appear to be able keep up with the speed of the PCIe interface. The file sizes are short of what I would expect.

But if I create a virtual RAMDisk and then cat to a RAMDisk then I have no problems. It would be nice to be able to skip the step of writing to the RAMDisk before transferring to SSD as I would like to save larger files. The SSD in question is a PCIe 4.0 device and I would have thought it would be more than capable of keeping up with my xillybus link running at approx 2.5GB/s.

Any suggestions?

Re: Fastest way to transfer to SSD

Postby support »


Acquiring data into SSDs is a common challenge, and as you've noted yourself, the fact that the SSD has a PCIe 4.0 interface doesn't necessarily reflect its effective data rate.

So for cases where the acquired data rate is higher than the storage, there's obviously no way around storing the data on RAM temporarily. I'll suggest three methods for that, starting with the least tempting one.

  • Use DDR memories attached to the FPGA directly. This method typically allows for the highest acquisition rate, independent of the host computer's performance and the PCIe link's bandwidth. It's in particular the preferred choice when the acquisition rate is in the order of magnitude of the computer's main bus' capabilities. However implementing this requires adding DDR memories to the hardware design, which is a known to be difficult. That said, development kits usually have such memories attached to the FPGA already. As for the FPGA design, this does a significant part of the work: ... oad-source
  • Use the "fifo" utility that comes along with the sample applications, which can be downloaded from the main download page:

    This utility allocates a lot of memory in user space, and functions as a huge FIFO from the device file to standard output. The disadvantage of this utility is that the data is copied from RAM to RAM one more time, which is significant when the data rate reaches several Gigabytes. When that's an issue, there's the third option:
  • Allocate huge DMA buffers. This requires a special host driver, as mentioned on this page:

    This option is cleaner in the sense that the same "cat" command can be used, but allocating huge DMA buffers is not a common thing to do, so it takes the operating system to an exotic use case situation. No problems are known so far in doing so, but one has to keep in mind that the kernel's memory manager wasn't written with say, 32GB of memory allocated for DMA, in mind.

For more on options 2 and 3 above, refer to section 4 of the Xillybus host application programming guide for Linux: ... _linux.pdf

(or the same section in the same guide for Windows)

Posts: 780

Return to Xillybus