Monday, February 28, 2011

[Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011

Further, I found that at the packet size of 1500B, the interval between
two packet transmissions must be less than about 20ms (on an intel
i5-M20 processor); otherwise, the received side couldn't not receive any
packets. This interval decreases as the packet size decreases.

Andrew

On 02/28/2011 11:21 AM, Feng Andrew Ge wrote:
> 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<gefengflorry@gmail.com>
> Subject: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
> To:discuss-gnuradio@gnu.org
> Message-ID:<4D696E4A.9050404@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

No comments:

Post a Comment