AnsweredAssumed Answered

Overflows while writing samples to binary files

Question asked by SMiles on Jul 23, 2015
Latest reply on Jul 27, 2015 by SMiles

Continuing from the discussion here, I have written some test code (attached) adapted from some of the examples in libiio to read and write samples to and from a binary file. Both programs function pretty much as expected, but I'm having some performance issues. It's worth noting that I have removed the code which sets the samplerate in the device, as I am using an FMCOMMS5, and simply setting the "samplerate"  attributes in the phy and phy-B devices did not work properly. I plan on referencing the new GNU radio blocks Paul just posted in order to better determine how this parameter should be set, but for the time being I am just setting it in IIO oscilloscope. I am also primarily relying on an external LO, so I haven't bothered adding a prompt for entering a value for that parameter. It's also still very much a WIP so there are some functions in there that I'm not using any more, and probably some variables as well.


At low samplerates (1-4MSps), I'm able to achieve nearly bit-perfect transmission using GMSK samples calculated by GNU radio. Additionally, the Tx program is able to run with a samplerate setting of up to 30MSps with no buffer underflows detected. However, the Rx program can only achieve up to 4MSps before I start getting overflows, which once I demod the waveform in GRC is reflected in small chunks of data missing from the output. I was just wondering, given my limited CS background, if anyone might have some suggestions for better optimizing this code that I might manage somewhat higher samplerates without overflow? One interesting behaviour I noticed is that at samplerates close to the threshold (4-6MSps), the first ~20-50MBytes of sample writes are managed without overflow, but after that point overflows occur regularly, and with increasing frequency the higher I set the samplerate.


I'm somewhat surprised that it's the Rx program that's struggling, since it doesn't have to deal with all of the conditional checks for handling EOF. Does fwrite() just have much slower performance than fread()? One thing I plan on trying is replacing the fwrite() calls with memcpy() calls to an intermediate buffer larger than the iio_buffer which I will then write to the file at shutdown, however I have some concerns with this approach - A) I don't really know if memcpy() performs markedly better than fwrite(), and B) these waveform files are massive (~10-100 times the size of whatever source file I am modulating), and I'm not sure that these boards have enough space in the heap on these zynq boards for an array that large.


Again, any other ideas are welcome. Thanks for the assistance!