[USRP-users] recv_frame_size and num_recv_frames for B210

Dario Fertonani dario.fertonani at gmail.com
Thu Jul 9 13:40:06 EDT 2015

Thank you Michael.
Can you please confirm/correct the following?

   - The parameter num_recv_frames sets the maximum number of frames that
   can be buffered. If this buffer fills up an ERROR_CODE_OVERFLOW is thrown.
   - Each of the num_recv_frames buffers is allocated a size of
   recv_frame_size bytes.
   - The "frame" concept for num_recv_frames and recv_frame_size is the
   same as for the "spp" option used for rx_stream args as at
   https://github.com/EttusResearch/uhd/wiki/Latency. For example, if I set
   spp to 1000 [and 1000 <= rxStream->get_max_num_samps( ) ], then the "frame"
   has 1000 samples even when recv_frame_size is "oversized" to 65536.

The above points are more critical then the following ones, which are just
about avoiding memory waste.

   - If I set num_rec_frames to 32 in a 2 rx system (we use B210), does
   that mean 32 frames for each antenna or 32 frames overall (16 frames for
   each antenna)?
   - If I use float32 as CPU format (8 bytes per complex sample) and set
   spp to 1000, can I assume that each frame will effectively use 8000 bytes,
   or is there some major overhead to account for?


On Thu, Jul 9, 2015 at 9:27 AM, Michael West <michael.west at ettus.com> wrote:

> Hi Dario,
> Increasing the buffering on the receive side will not change the average
> latency, but will allow for a higher peak latency.  The fact that
> increasing the buffering resolved the overflow issue indicates that the
> buffer was not being drained fast enough, which suggests that the
> application has excess latency between recv() calls.  This is commonly
> caused by the thread performing some sort of IO operation (such  as writing
> data to disk).
> Regards,
> Michael
> On Wed, Jul 8, 2015 at 10:18 AM, Dario Fertonani via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>> I was able to eliminate the rare overflow errors just by using higher
>> values of recv_frame_size and num_recv_frames for the rx stream. Our stack
>> easily meet the timeline, so we're looking at eliminating rare overflow
>> errors due to the non-deterministic nature of the non-real-time OS (in our
>> case, Ubuntu 14.04 low latency), rather than to slow stack processing.
>> Any drawback in using high values of recv_frame_size and num_recv_frames,
>> besides memory usage/waste? For example, I don't fully understand what
>> happens when num_recv_frames is bumped up to 256 from the default value of
>> 16. Does the worst-case latency increases by 16 times?
>> Thanks,
>> Dario
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150709/24acf13a/attachment-0002.html>

More information about the USRP-users mailing list