|Subject:||Re: [Discuss-gnuradio] How to make USRPs transmit and receive within 1 millisecond?|
|Date:||Fri, 10 Feb 2017 11:38:18 +0100|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0|
Hi Amarja Vaidya,
first off: GNU Radio is massively multithreaded, so you mustn't
just look in the top_block.py main thread; at low rates, however,
it's totally correct that the flow graph will mostly idle, since
GNU Radio works in a manner where the sample sources fill the
buffers they have as fast as possible, and the sinks consume as
fast as they can - and in the case of the USRP sink, that is the
sampling rate you use.
Yes, it's possible to bring down latency, but it's a hard task. It will require you to use small buffers of packets between host and USRP, it'll require you to optimize your system so that interrupts from the network card are handled swiftly, it puts a hard limit on the length of your communication packets and so on.
You forgot to mention which sampling rate, data packet size
you're using – but if it's anything comparable to what benchmark_*
does by default, no, 1ms roundtrip is mathematically impossible
(default OFDM FFT size = 512; sampling rate = 500 kHz –> packet
duration + cyclic prefix > 1ms); please check your math!
Also, benchmark_rx/_tx shouldn't be used anymore. They are obsoleted by the newer OFDM blocks that you will find in rx_ofdm.grc and tx_ofdm.grc. Since you'll be modifying things, I can only recommend using that infrastructure instead. We cannot help you with benchmark_rx/_tx.
There is a hard limit on how fast software on a PC can
react to a packet. I'm not sure 1ms roundtrip is going to be easy.
On 10.02.2017 11:22, Amarja Vaidya wrote:
|[Prev in Thread]||Current Thread||[Next in Thread]|