Josh, Thanks for sharing the information and your changes sound quite reasonable.
However, it seems that your changes have introduced some bugs at the transmitter side. I updated my system using your new code (following your instructions in your Feb. 24's email titled "Re: GRC + N210 + RFX2200 + UHD not working"); then I ran python-based benchmark_tx.py. I tested two cases: in the first case, I sent packets continuously and it worked well; in the second case, I sent packets every second and the transmitter side could send only about 10~12 packets, then stopped sending data into USRP2 (based on observation from wireshark results). Both cases used 1500B for each packet and the send-buff-size was 100kB.
Would you please take a look at this? Andrew ---------- Message: 3 Date: Sat, 26 Feb 2011 16:19:06 -0500 From: Feng Andrew Ge<gefengflo...@gmail.com> Subject: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011 To:discuss-gnuradio@gnu.org Message-ID:<4d696e4a.9050...@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Josh, When you say "2x" performance increase, do you mean CPU performance or send()/recv() latency? Do you mind saying a few words on what changes you have made? Andrew --------------- Much of the performance gains involved removing things out of the fast-path that only needed to be called once at initialization (forgoing code simplicity for performance). Example: a vector of pointers, a bound callable object; many of which had calls to malloc and free which incurs quite a lot of unnecessary overhead. Less cpu cycles/less time are spent in the send()/recv() calls. This roughly worked out to about half the CPU usage when looking at oprofile. Because of this, the overall latency is reduced. We measured about 250us RTT from device to host and back to device with the latency measurement app in uhd examples. -josh _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
