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<address@hidden>
Subject: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
To:address@hidden
Message-ID:<address@hidden>
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