[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Josh Blum
Subject: Re: [Discuss-gnuradio] UHD's recv_frame_size for E100
Date: Tue, 26 Apr 2011 12:07:04 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

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:


> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]