Re: [Discuss-gnuradio] UHD's recv_frame_size for E100

[Josh Blum]

On 04/25/2011 06:34 PM, Michael Dev wrote:
> Yes, improved latency with smaller frame size is what I'm looking for.  506
> samples of buffering is pretty big for me.  Also, being able to adjust the
> frame size to a nice size for my app would mean I don't have to have some
> additional buffering code (and the code to 'manufacture' rx timestamps for
> fragments that don't come with timestamps) between the recv() call and
> feeding the result to my app.
> 

Can you try this branch:
http://code.ettus.com/redmine/ettus/projects/uhd/repository/show?rev=usrp_e100_frame_sizes

-Josh

> Michael
> On Mon, Apr 25, 2011 at 6:08 PM, Josh Blum <address@hidden> wrote:
> 
>>
>>
>> On 04/25/2011 06:01 PM, Philip Balister wrote:
>>> On 04/25/2011 08:28 PM, Michael Dev wrote:
>>>> Unlike USRP1 over USB, it seems specifying the recv_frame_size on "args"
>>>> doesn't have any effect on E100.  I see get_max_recv_samps_per_packet()
>>>> always returning 506 and I see fragmented segements from recv() calls.
>>>> Is it
>>>> unadjustable for E100 or am I doing something wrong here?
>>>
>>> Due to the design of the fpga interface, the largest transfer between
>>> the fpga and gpp is 2048 bytes. Beyond this, Josh will need to comment :)
>>>
>>
>> I didnt put in the hooks to change the frame size. It should be possible
>> without too much fuss. Right now, the frame size defaults to the maximum
>> size of the kernel ring buffer frames, or optimized for bandwidth. This
>> hook would allow you to make the frames smaller (optimized for latency).
>> Is that what you are looking for?
>>
>> -Josh
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>