Re: USRP N210 growing latencies

[Marcus Müller]

Hi Fabien,

risking sounding a bit cliché: Well, you need to fix your bug. The underflow 
should not be
happening!

An easy solution, if this is just a manner of occasionally insufficient, but
on-the-medium-term more-than-sufficient processing speed, a larger buffer 
between the USRP
source and the next block, maybe?

Maybe we can otherwise help you improve the performance of your application :) 
Just let us
know!

Best regards,
Marcus

On 30.10.21 00:20, Fabien PELLET wrote:
> Hi,
> 
> Thanks for the answer.
> 
> At the moment, it seems that catching the underflow message and then 
> lock/unlock the
> flowgraph permits to reset the buffers and is enough for my application to 
> get reasonnable
> and not growing forever latencies. I don't if someone know a better way like 
> a C++ method
> that could do that more "elegantly".
> 
> If I need more predictible latencies in the futur, indeed, I will try to use 
> tags as you
> suggest.
> 
> Regards,
> 
> Fabien, F4CTZ.
> 
> Le 27/10/2021 à 17:02, Sylvain Munaut a écrit :
>> Hi,
>>
>>
>>> OK I understand that. But is there any solution which permits to reset that 
>>> growing
>>> propagation delay ? How to reset the flowgraph buffers without killing the 
>>> application
>>> and restart it ? Is there any method that permits to purge and resync 
>>> buffers of the
>>> flowgraph ?
>> The USRP supports timestamps for RX and TX.
>> So you get tags for when data was received / is supposed to be transmitted.
>> Using a custom block to modify the RX tags into TX tags ( to change
>> the RX timestamps to TX timestamps a bit into the future ), you should
>> be able to achieve a constant controlled latency.
>>
>> Cheers,
>>
>>      Sylvain
>

smime.p7s
Description: S/MIME Cryptographic Signature