discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Michael Dev
Subject: Re: [Discuss-gnuradio] UHD's recv_frame_size for E100
Date: Tue, 26 Apr 2011 16:00:31 -0700

It seg faults on me.
Opening USRP-E on /dev/usrp_e0
USRP-E100 clock control: 6
r_counter: 1
a_counter: 0
b_counter: 12
prescaler: 8
vco_divider: 2
chan_divider: 15
vco_rate: 1920.000000MHz
chan_rate: 960.000000MHz
out_rate: 64.000000MHz
[New LWP 847]
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 847]
0x401ff524 in usrp_e100_impl::io_impl::recv_pirate_loop (this=0x92e20, spawn_barrier=<value optimized out>, clock_ctrl=...)
at /home/root/uhd-new/uhd/host/lib/usrp/usrp_e100/io_impl.cpp:116
116 managed_recv_buffer::sptr buff = this->data_xport->get_recv_buff();


On Tue, Apr 26, 2011 at 12:07 PM, Josh Blum <address@hidden> wrote:


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
>>
>


reply via email to

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