Re: USRP N210 growing latencies
Hi Marcus, How to increase the size on the buffer at the output of the USRP source ? Improve my flowgraph : maybe possible but I already did some improvment ? I cascade 3 Xlating FIR filter with growing decimation (5, 10, 25) and already try to limitate the number of taps. I have to work with a 12,5Msps source, make my duties at 10ksps and then output to the sink at 200Ksps (the lowest value of the USRP). I tried XLating FFT filter but it was worst. Thanks for your help, Regards, Fabien, F4CTZ. Le 31/10/2021 à 13:03, Marcus Müller a écrit : 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
Re: USRP N210 growing latencies
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
Re: USRP N210 growing latencies
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
Re: USRP N210 growing latencies
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
Re: USRP N210 growing latencies
Hi Johannes, I try on 2 configurations : - VM Ubuntu 20.04 + GR 3.9.3.0 + UHD 4.1.0.4 - Native LXubuntu 20.04 Prempt kernel + GR 3.9.4.0 + UHD 4.1.0.4 All are built from sources. RX SR = 5Msps TX SR = 200ksps All seem to be supported by N210. Yes I decimate with the write value (RX SR / TX SR). On the VM system, I see a lot of underflow that appear randomly. I could measure up to near a second of propagation delay in the flowgraph after 10min working period : it's unusable. Indeed, working with a native Preempt linux distribution eliminate near all underflow. But sometimes, maybe when OS generates an interrupt with higher priority, I could get one underflow : one underflow in that case in 8H working period. I can accept that if I can reset the flowgraph just after without killing it and restart. The question is how ? Best regards, Fabien, F4CTZ. Le 27/10/2021 à 14:47, Johannes Demel a écrit : Hi Fabien, unless this is a very specific issue and you know exactly that your OS is the component that causes an issue, I recommend to stick with your distros generic kernel image. I'd need more information but my gut feeling tells me that your issue is somehow a 2-clock problem. So let's start with a few questions about your system. Which Linux distribution do you use? Which exact GNU Radio and UHD versions do you use? GR 3.9.3? UHD 4.1.0.x? How did you install GNU Radio. Do you run your flowgraph in a VM or smth similar? UHD RX sample rate? UHD TX sample rate? Are both rates supported by your N210? Does your flowgraph decimate by some integer value? Which blocks are in between? Just to get this out of the way, another hardware block such as an audio sink might get you into a 2-clock problem situation. Since you use hardware blocks, I assume you don't use a Throttle block, if so, remove the Throttle block. Can you share the flowgraph? It might be easiest to just write down the exact blocks. Are there any custom blocks? Do you need continuous streaming? How fast does the delay grow? A lot of questions, I know. The answers to these questions might help to find your root issue. Cheers Johannes On 26.10.21 21:41, Fabien PELLET wrote: Hello, Thanks for the answer Marcus. 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 ? Even if my application runs on a preempt_rt OS with a good calculation power, I'm not enough good in Linux tweaking to be sure that my application will not have a unusable delay after a long time. So I can accept to loose some time when I catch a PMT message of underflow to reset the sequencer and buffers. But how without killing apps ?? Best regards, Fabien, F4CTZ Marcus Müller a écrit Hello! On 26.10.21 16:12, Fabien PELLET wrote: > > Why that propagation delay is always growing ? > Exactly *becuause* your underflowing. Your Receive side produces N samples – but too slow at some point, leading to your transmitter needing to "invent" an amount P of samples, because it simply has a fixed sample rate. So, now, from the point of view of the transmitter's DAC, N+P sample periods have passed, whereas the receiver's ADC saw N sample periods. This repeats, and every P > 0. Therefore, the delay is always only growing. Best regards, Marcus options: parameters: author: osboxes catch_exceptions: 'True' category: '[GRC Hier Blocks]' cmake_opt: '""' comment: '' copyright: hgjhg description: hjhghg gen_cmake: 'On' gen_linking: dynamic generate_options: qt_gui hier_block_src_path: '.:' id: testcpp max_nouts: '0' output_language: python placement: (0,0) qt_qss_theme: '' realtime_scheduling: '' run: 'True' run_command: '{python} -u {filename}' run_options: prompt sizing_mode: fixed thread_safe_setters: '1' title: test states: bus_sink: false bus_source: false bus_structure: null coordinate: [8, 8] rotation: 0 state: enabled blocks: - name: samp_rate id: variable parameters: comment: '' value: '500' states: bus_sink: false bus_source: false bus_structure: null coordinate: [184, 12] rotation: 0 state: enabled - name: analog_agc2_xx_0 id: analog_agc2_xx parameters: affinity: '' alias: '' attack_rate: 10e-3 comment: '' decay_rate: 5e-1 gain: '1.0' max_gain: '65536' maxoutbuf: '0' minoutbuf: '0' reference: '0.4' type: complex states: bus_sink: false bus_source: false bus_structure: null coordinate: [672, 388.0] rotation: 0 state: enabled - name: fir_filter_xxx_0 id: fir_filter_xxx parameters: affinity: '' alias: '' comment: '' decim: '25' maxoutbuf: '0'
Re: USRP N210 growing latencies
Hi Fabien, unless this is a very specific issue and you know exactly that your OS is the component that causes an issue, I recommend to stick with your distros generic kernel image. I'd need more information but my gut feeling tells me that your issue is somehow a 2-clock problem. So let's start with a few questions about your system. Which Linux distribution do you use? Which exact GNU Radio and UHD versions do you use? GR 3.9.3? UHD 4.1.0.x? How did you install GNU Radio. Do you run your flowgraph in a VM or smth similar? UHD RX sample rate? UHD TX sample rate? Are both rates supported by your N210? Does your flowgraph decimate by some integer value? Which blocks are in between? Just to get this out of the way, another hardware block such as an audio sink might get you into a 2-clock problem situation. Since you use hardware blocks, I assume you don't use a Throttle block, if so, remove the Throttle block. Can you share the flowgraph? It might be easiest to just write down the exact blocks. Are there any custom blocks? Do you need continuous streaming? How fast does the delay grow? A lot of questions, I know. The answers to these questions might help to find your root issue. Cheers Johannes On 26.10.21 21:41, Fabien PELLET wrote: Hello, Thanks for the answer Marcus. 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 ? Even if my application runs on a preempt_rt OS with a good calculation power, I'm not enough good in Linux tweaking to be sure that my application will not have a unusable delay after a long time. So I can accept to loose some time when I catch a PMT message of underflow to reset the sequencer and buffers. But how without killing apps ?? Best regards, Fabien, F4CTZ Marcus Müller a écrit Hello! On 26.10.21 16:12, Fabien PELLET wrote: > > Why that propagation delay is always growing ? > Exactly *becuause* your underflowing. Your Receive side produces N samples – but too slow at some point, leading to your transmitter needing to "invent" an amount P of samples, because it simply has a fixed sample rate. So, now, from the point of view of the transmitter's DAC, N+P sample periods have passed, whereas the receiver's ADC saw N sample periods. This repeats, and every P > 0. Therefore, the delay is always only growing. Best regards, Marcus
Re: USRP N210 growing latencies
Hello, Thanks for the answer Marcus. 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 ? Even if my application runs on a preempt_rt OS with a good calculation power, I'm not enough good in Linux tweaking to be sure that my application will not have a unusable delay after a long time. So I can accept to loose some time when I catch a PMT message of underflow to reset the sequencer and buffers. But how without killing apps ?? Best regards, Fabien, F4CTZ Marcus Müller a écrit >Hello! > > >On 26.10.21 16:12, Fabien PELLET wrote: >> >> Why that propagation delay is always growing ? >> > >Exactly *becuause* your underflowing. > >Your Receive side produces N samples – but too slow at some point, leading to >your >transmitter needing to "invent" an amount P of samples, because it simply has >a fixed >sample rate. > >So, now, from the point of view of the transmitter's DAC, N+P sample periods >have passed, >whereas the receiver's ADC saw N sample periods. This repeats, and every P > >0. Therefore, >the delay is always only growing. > >Best regards, >Marcus >
Re: USRP N210 growing latencies
Hello! On 26.10.21 16:12, Fabien PELLET wrote: > > Why that propagation delay is always growing ? > Exactly *becuause* your underflowing. Your Receive side produces N samples – but too slow at some point, leading to your transmitter needing to "invent" an amount P of samples, because it simply has a fixed sample rate. So, now, from the point of view of the transmitter's DAC, N+P sample periods have passed, whereas the receiver's ADC saw N sample periods. This repeats, and every P > 0. Therefore, the delay is always only growing. Best regards, Marcus
USRP N210 growing latencies
Hello, I'm using Gnuradio 3.9 and UHD 4.1 with a N210 with only LFRX and LFTX. I'm using USRP_source to receive samples, make some treatment in a flowgraph and especially a decimation, and finally send the samples to an USRP_Sink to get an analog signal resulting of my treatment. My system is not perfect and a get some underrun sometimes. At each underrun, the propagation delay is keep growing more and more. I can measure that using an oscilloscope between input signal and output signal. Why that propagation delay is always growing ? Is there a way to reset the overall propagation delay at each underrun that I could catch using PMT message in a C++ application ? Thanks for your help, Best regards, Fabien, F4CTZ.