Bladerf 2.0 buffer_size and num_buffers

[kennyr]

Hi,

- what is the maximum size of buffer_size for bladerf 2.0?

I've seen BUFFER_SIZE = 32 * 1024 = 32768;
https://github.com/Nuand/bladeRF/blob/e ... src/main.c

- What is the difference between BUFFER_SIZE=2048 and num_buffers=1 and BUFFER_SIZE=1024 and num_buffers=2 for instance?

Thanks,

[robert.ghilduta]

The parameter to bladerf_sync_config are host-side software settings. It is up to the OS to determine how much memory it will allow to be allocated to the user mode program that loaded libbadeRF. Generally a good rule of thumb is anything from as low as a few 10s of kilobytes to several seconds of captures worth of memory.

BUFFER_SIZE controls the size of the libusb call. A smaller BUFFER_SIZE fills up more quickly so it has lower "latency" but it incurs a performance impact by doubling the calls for libusb. BUFFER_SIZE should be at least 1024 but should be kept under 1048576.

[kennyr]

- should be at least 1024 but should be kept under 1048576

Is this for each port? Can I fetch 1048576 samples on each port or does it reduce when using more than one port?

Thank you

[robert.ghilduta]

The buffer sizes are for individual IQ samples. When running in MIMO it will eat through the buffer space twice as "fast" based on the number of samples that are requested in bladerf_sync_rx()

[kennyr]

Sorry I still didn't understand.
Is it a shared buffer or each port supports a 2^20 samples?

Thanks,

[robert.ghilduta]

The buffers being allocated by libbladeRF are on the host PC. The buffer sizes are in bytes, the conversion into samples sizes has to be done by the program utilizing libbladeRF. User mode memory already isn't physically contiguous. Fortunately USB xHCIs tend to have scatter gather DMA engines so physically non-adjacent pages are "stitched" together by the kernel and DMA engine.