Thanks Jordan, this is super helpful.
I made the uhd/gr-uhd changes that josh suggested and using the following
code snippet. I now can see EVENT_CODE_BURST_ACK (event code == 0)
messages coming back from UHD at approximately 30msec intervals.
self.async_msgq = gr.msg_queue(0)
self.uhd_amsg_source_0 = uhd.amsg_source("addr=192.168.102.1",
self.async_msgq)
self.async_rcv = gru.msgq_runner(self.async_msgq, self.async_callback)
def async_callback(self, msg):
md = self.uhd_amsg_source_0.msg_to_async_metadata_t(msg)
print "Channel: %i Time: %f Event: %i" % (md.channel,
md.time_spec.get_real_secs(), md.event_code)
In josh's example he sets the user_payload field with presumably a buffer
occupancy value. I'm getting lost in the swiggyness here and can't figure
out how to print a value of type <Swig Object of type 'uint_fast16_t *' at
0x9894188> any suggestions there?
I'm guessing what you are doing is writing a block which handles messages
and in the event the occupancy drops below a certain amount, you write more
source data out.
On Tue, Apr 23, 2013 at 2:17 PM, Jordan Otomo <[email protected]> wrote:
> Hi Phelps,
>
> I've been dealing with latency issues of my own, and this seems to be the
> best solution so far (big thanks to Josh!):
>
> http://lists.gnu.org/archive/html/discuss-gnuradio/2013-04/msg00211.html
>
> The nice thing about this method is that it allows you to manage buffering
> at a system level as opposed to per-block. I've been able to limit my
> latency to about 50 ms, but you can probably do better depending on how
> much processing you're doing. Hope this works for you!
>
> Jordan
>
>
> On Apr 22, 2013, at 10:59 PM, Phelps Williams wrote:
>
> I created a block which in the work(), sits in select on a udp socket with
> a timeout of 10msec. In the event it times out rather than getting a read
> signal, a pattern of noutput_items is written. In the event it receives
> data from the udp socket, the udp dgram is copied to the output items
> vector. This flowgraph ends with a UHD USRP sink.
>
> I am consistently observing latency through my flow graph of around 2 -
> 2.5sec. The total latency doesn't appear to be dependent on the sample
> rate (I've tested 1Msps and 2Msps). When intentionally underruning the
> flow graph by setting set_max_noutput_items to less than 10msec of samples,
> the latency through the graph is between 80msec and 200msec.
> Intentionally underrunning UHD isn't an option for my application as an
> intermittent modulated signal from the USRP causes issues.
>
> I am attempting to use the global (via gr.top_block.start()) and block
> specific max_noutput_items settings to limit the total amount of latency in
> my flow graph but this doesn't appear to be the primary source of latency.
>
> My suspicion is that UHD or the USRP has a transmit buffer which is the
> source of my problem. I tried messing with the send_buff_size and
> recv_buff_size specified here:
> http://files.ettus.com/uhd_docs/manual/html/transport.html but these
> didn't seem to make any impact.
>
> I played with setting set_max_noutput_items on the source block to the
> exact value expected during the 10msec select timeout in my custom source
> block. This works for a while but occasionally underruns. Also as udp
> traffic moves through the block, the total amount of latency slowly
> increases. It also seems wrong to throttle the flowgraph at both the
> source and the sink. Much like it is problematic to use a throttle with a
> UHD source or sink block. set_max_noutput_items doesn't seem like the
> right solution for this problem.
>
> Decreasing GR_FIXED_BUFFER_SIZE in gr_flat_flowgraph makes a significant
> improvement but it isn't a viable option for my application because it is a
> universal setting for all gnuradio based radios running on my system. Some
> of which require the default buffer size to operate efficiently.
>
> There has been a little discussion of this topic on the mailing list in
> the past but I haven't found examples that include UHD / USRP with a
> flowgraph that isn't intentionally underrunning (ie with a typical UDP
> source block).
>
> I have messed with the maximum socket buffer sizes allowed by linux. The
> uhd recommended config and much smaller variations don't appear to make an
> impact to this latency.
> $ sudo sysctl net.core.rmem_max
> net.core.rmem_max = 50000000
> $ sudo sysctl net.core.wmem_max
> net.core.wmem_max = 1048576
>
> For reference I am running:
> UHD 003.005.002
> Gnuradio 3.6.4.1
>
> *tl;dr*
> My expectation is that there is a buffer UHD is attempting to maintain,
> when this buffer gets low, it triggers upstream work operations in the
> flowgraph to refill this buffer. Is this not the case? How can I
> manipulate the size of this buffer? Is there any way to confirm the size
> of this buffer?
>
> Thanks!
>
> -Phelps
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
