[USRP-users] performance issues

Josh Blum josh at joshknows.com
Tue Nov 30 10:10:21 EST 2010


You may be seeing the effect of the host-based throttling. You can
disable the host based throttling to see if this is the case (in doing
so the flow control will fall back to ethernet pause frames).

comment out line 146 in lib/usrp/usrp2/io_impl.cp
if (not fc_mons[i]->check_fc_condition(fc_word32, timeout)) return false;

----------------------------------------------------------------------

If it turns out that is is the new host-based throttling, then you may
want to tweak it. In lib/usrp/usrp2/mboard_impl.cpp, lines 101 and 107
have default update rates, you may want to make these more often.

Comment out 104 to enable the updates per second:
_iface->poke32(_iface->regs.tx_ctrl_cycles_per_up, 0); //cycles per
update is disabled

These parameters can also be tweaked from the device address:
http://www.ettus.com/uhd_docs/manual/html/transport.html#flow-control-parameters

I hope that in the end, this is just an issue of tweaking the flow
control update rates.

-Josh

On 11/30/2010 01:17 AM, Per Zetterberg wrote:
> On Tue, 2010-11-30 at 00:42 -0500, Josh Blum wrote:
>>> Let me clarify. I transmit frames between two usrp2+laptop at 25Msamp/s.
>>> The two USRPs take turns at transmitting. Thus every other frame goes
>>> into from "A->B" and the others "B->A".  I do it at regular time
>>> intervals using time stamps where "time_stamp_i = i * time_inverval".
>>> With the old UHD I was able to use timer_interval=6ms with the new UHD I
>>> need at least time_interval=100ms. 
>>>
>>>
>>
>> There was a bug in the FPGA code where the first packet of a consecutive
>> timed-burst was dropped and the subsequent packets of that burst sent
>> ASAP. You may be seeing the effect of the packets being sent properly
>> because as of the last image, this should not have worked.
>>
>> Since you are seeing lots of underflow, how early are you sending the
>> packets to the device? Meaning, how many ms before the timestamp on the
>> packet?
>>
>> -Josh
>>
> 
> I only changed the UHD in one of the two ends of the link. I think it
> was on the node that transmits in the first frame. At 100ms I am seeing
> a single overrun as I can recall. At smaller time intervals it will
> print out a few more and then hang. The node that transmits the first
> frame will send the frame about two seconds in advance. Then it will
> "issue_stream_cmd" with a "time_spec" which is set "time_interval" after
> the frame was transmitted. After this frame has been received it is time
> to transmit the next frame at another timer_interval later ......
> 
> 
> Thanks for the prompt response!
> 
> BR/
> Per
> 




More information about the USRP-users mailing list