Leaderboard

We could try running iperf, just to confirm it's the loopback adapter and not the code. But as I said, we've run the same code with 2 hardware NICs (10G) connected on the same computer and it works fine.

I believe you! 🙂 During testing of this release I came across a problem that first dumbfounded me. On most systems it seemed to work fine but when executing it in LabVIEW 7.1 on Windows it consistently crashed. The problem turned out to be memory alignment related. One of the data structures passed to the shared library happened to be 43 bytes long. Inside the shared library was however some assignment operator where an internal temperary variable of that structure located on the stack was first filled in and then assigned to the passed in variable. C does allow to assign whole structure variables by value and the compiler then generates code to copy the whole variable. Except that Visual C did not bother to make it exactly 43 bytes but simply copied 48 bytes which resulted in random trash from the stack being copied after the end of the variable. On most platforms LabVIEW seemed to align the parameters it was passing to the Call Library Node such that this extra buffer overwrite didn't collide with any of the other parameters , but in LabVIEW 7.1 it somehow always wanted to pack the paramers tightly so that this copying corrupted the buffer pointer passed to the next parameter of the function. This was normally supposed to be a NULL pointer but of course wasn't NULL after this assignment and then the shared library crashed. I'm pretty sure that this was also the reason why it normally would encounter trouble on 64-bit Linux. And no this problem did not exist in pre 4.1 versions. This particular structure got extended when I incorporated the latest minizip 1.2 sources from Nathan Moinvaziri to support 64-bit archive operation. Previous versions used the standard stock minizip 1.1 sources included in the zlib source distribution.

The DMA FIFO is silly fast if configured correctly. I have used it in a VST to losslessly stream (continuously for tens of hours) something on the order of several GB/s to disk. That was using PXI, and not myRIO though. Don't forget, the host (RT) is actually the place where data gets buffered, and this is where you can make a nice big buffer. You don't really need a big buffer on the FPGA, you just need to make sure you read from the host buffer fast enough. As Tim_S said, do the trick where you read zero samples, this will return no data but will give you the number of samples actually available.

He confuses OOD with OOP. Again. OOD.

I've gotten a test bench of 1 MS/sec of 32-bit data (24-bits plus 8-bits channel identifier) across FPGA->RT->Windows using DMA channel to RT FIFO to TCP and let it run overnight without drop of any data. Buffer was set to maximum size of U32. Now that was with a cRIO rather than a myRIO. Are you using NI's recommendations for best practices? Particularly the one where you check for available (request 0 samples) and then read all is a good way to read on the RT side. If you wait until the buffer is full then the FPGA can (and almost certainly will) overwrite before host side can service an interrupt.

Screwdrivers are $29.99 though, that's how they get you.

Maps in LabVIEW 2019?

We'll grow into it eventually 😋