The payload field contains the sequence numbers of packets consumed by the
USRP's DUC. As a note, you may need to reorder the bytes (uhd::ntohx). I'm
handling the messages in C++, so I'm not too sure about the swig. My source
reads the messages and calculates the number of samples consumed by the USRP
(this is possible because the USRP packet size is fixed). The number of
produced output samples are limited such that there are only N samples (50 ms)
between my source and the USRP's DUC.
On Apr 23, 2013, at 4:37 PM, Phelps Williams wrote:
> 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 <jot...@skybox.com> 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
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
