[TangerineSDR] Further Digital RF benchmarking results

[Engelke, Bill]

After last night's telco, I revisited some of the benchmarking work I have been doing with evaluating the Odroid XU4 for use with Digital RF. I tried more scenarios than would make sense to report here, but some possibly useful findings are as follows:


  1.  TEST SETUP - the Red-Pitaya (14 bit) was activated in HPSDR emulation mode, using John Melton's program pihspdr (enhanced to support Digital RF).
  2.  Digital RF was set up with 16 channels (this is 8 channels on each of 2 antennas).
  3.  This rig runs at 48 ksps (single channel of I & Q, each 4-byte floating point). The data from each received buffer was duplicated across the 16 channels, creating the Digital RF output buffer; then the buffer was written out 4 times ( 4 X 48 ksps ) to simulated 192 ksps for each buffer received.
  4.  On advice from Ryan Volz (MIT), the data was written out to RAM disk (supposedly the fastest possible way to do this).
  5.  Vector lengths of 200 through 1200 were tried; also various subdirectory cadences and msec-per-file settings were tried.
  6.  RESULTS - a vector length of 200 to 400 seemed to be the fastest (i.e., with least missed data). Msec-per-file and subdirectory cadence did not seem to make much difference in performance. Missed data: at varying intervals ranging from 14 to 43 buffers, the system would report that it missed 6 or 7 received buffers- a loss rate of 16% to almost 50%. Threading: it appears that Digital RF has some threading: htop showed that 4 of the Odroid cores had significant activity (but remember that pihpsdr also does some threading even without Digital RF).  If the number of channels was cut in half (a scenario with monitoring 4 bands, 2 antennas each), there was no data loss.
  7.  GNURadio - additional discovery - I have not found a way in GHNRadio to handle a Digital RF file that contains multiple channels. Both Digital RF source modules have errors (either wanting the channels in separate subdirectories or complaining about the number of channels creating a mismatch). I am working with Ryan Volz on this. Further, the Digital RF source that purports to be able to handle multiple channels supports a maximum of 10 channels, so 16 won't work.



Random Related Thoughts

  *   Writing to RAM disk may be the way to go if we want to create the data directly in Digital RF format. MIT has a utility that can run in the background to move these from RAM disk to somewhere else.
  *   Results above will be different with the Odroid N2 (one is supposed to be delivered to me on Friday). Also - by the time we get to 2024, there may be a SBC even faster.
  *   Failing everything, it is probably possible to output the data as raw binary and later convert to Digital RF (assuming we don't go beyond the total I/O bandwidth of the SBC).


W. D. Engelke (Bill), Asst. Research Engr.
Center for Advanced Public Safety
Cyber Hall
The University of Alabama
Tuscaloosa, AL 35487
Desk: (205) 348-7244
Mobile: (205) 764-3099

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20190702/ebe63371/attachment-0001.html>