On 03/01/2011 04:39 PM, Feng Andrew Ge wrote: > Josh, > > Your explanation makes sense. Is there a quick fix for me to bypass > this problem temporarily while you are working on the modification. >
http://gnuradio.org/cgit/jblum.git/commit/?id=75538e12300cb0d593792a986841ba2df9997c54 :-) > Further, following your current bandwidth optimization implementation, > is the code trying to fill the buffer in both uhd_single_usrp_sink > (sending buffer) and uhd_single_usrp_source (receiving buffer)? > For the source, the work function waits for the entire RX buffer to be filled with samples. I strongly believe this is the cause of the latency. For the sink, the work function sends the entire buffer. This is correct behavior for optimum latency and bandwidth. > When I started uhd_benchmark_tx.py, it also asked for specification of > *recv_buff_size, where is it used? * > http://www.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buffers -Josh > > On 03/01/2011 07:01 PM, Josh Blum wrote: >> >> On 03/01/2011 03:25 PM, Feng Andrew Ge wrote: >>> Josh, >>> >>> Everything is in the attachment, look for python-based UHD_* code. >>> >>> The performance before and after Feb.25 was both poor. At one point >>> before Feb. 25, the latency was even worse, up to>30ms. But I forgot >>> the time. >>> >>> In terms of GNU Radio, for running UHD I checked out next from GNU Radio >>> git. However, for raw Ethernet, I only ran GNU Radio 3.3.0. I haven't >>> found time to check GNU Radio changes yet, what might cause such huge >>> performance drop. >>> >> Andrew, >> >> Here is an idea that may explain your problem: >> >> When the raw ethernet source calls into work(), it does not attempt to >> fill the entire buffer (noutput_items). Rather, it waits at least one >> packet to become available and then copies only the data that is >> available immediately into the buffer. >> >> In contrast, the UHD work function is bandwidth optimized and tries to >> fill the entire buffer. At your sample rate (500ksps), this will impose >> serious delays for very large noutput_items (10s of thousands). I hope >> that explains the issue you see. >> >> I am going to attempt a modification to the work function, where we recv >> a single packet with timeout, and then anything else that is available >> without waiting. >> >> I will let you know when I post a branch with changes. >> -Josh >> >>> Andrew >>> >>> On 03/01/2011 06:13 PM, Josh Blum wrote: >>>> On 03/01/2011 02:21 PM, Feng Andrew Ge wrote: >>>>> Josh, >>>>> >>>>> First of all, I am aware of what you pointed out and I did use the >>>>> code >>>>> latency_test.cpp for measuring latency between USRP2 and a host. The >>>>> latency is negligible. >>>>> >>>> Ok, i see. You were measuring the ping time over the tunnel. :-) >>>> >>>> Can you tell me: Is this a new problem with UHD since the " February >>>> 25rd 2011" announcement. That is, was it working properly for you >>>> previously? >>>> >>>>> I think I was not clear enough in my previous email. >>>>> My setting is this: host_1--USRP2_1 talks to host_2--USRP2_2. The >>>>> latency I measured is based on GNU Radio-created wireless network >>>>> interface, e.g., gr0. I started tunnel.py and created a digital link >>>>> between host_1 and host_2; then I compared ping RTT time performance >>>>> between using the UHD code and using the Raw_Ethernet code base. UHD >>>>> introduced 9 ms of overhead and I am really puzzled about this. Since >>>> I am puzzled as well. 9ms sounds pretty bad. Is this a port of >>>> tunnel.py >>>> to UHD, can you share it? >>>> >>>>> USRP2 sends samples immediately out and the latency between the >>>>> host and >>>>> USRP2 is negligible, the likely place I can think of is the interface >>>>> between UHD and GNU Radio, for example, can UDP packet sending be >>>>> preempted by other threads? Each time how many UDP packets can be >>>>> possibly sent out? >>>>> >>>> The work function is called with a randomly sized buffer determined by >>>> the scheduler. The number of packets received or sent depends on the >>>> size of the buffer when the work() function is called. >>>> >>>> I think this is exactly the same for the raw_ethernet driver. >>>> >>>> It may be helpful to print the number of items in the work function. It >>>> seems to be in the 10s of thousands of samples last I looked. >>>> >>>> When you compared UHD vs raw_ethernet driver, it was all the same >>>> version of gnuradio, correct? >>>> >>>>> Another possibility is how you allocate CPU resources in handling UHD >>>>> and what the impact might be. >>>>> >>>>> The third possibility is buffer management: how do you handle buffer >>>>> management in UHD for sending and receiving? How do data stay in those >>>>> buffers and how are data are processed, by FIFO or LIFO? If overflow >>>>> happens, will newly coming packets get simply dropped? >>>>> >>>> Nothing gets buffered in the UHD in the usrp2/n210 implementation. >>>> However, there is a kernel socket buffer on receive that has enough >>>> buffering for a second of samples. Once this buffer fills, newer >>>> packets >>>> are dropped. >>>> >>>> I also believe that this is the same on the raw ethernet driver. >>>> >>>> -josh > > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
