[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] New implementation for fusb_linux withoutallocs/f
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] New implementation for fusb_linux withoutallocs/frees |
Date: |
Tue, 24 Feb 2009 09:21:16 -0800 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Tue, Feb 24, 2009 at 10:03:05AM -0500, Marcus D. Leech wrote:
> Stefan Bruens wrote:
> > Hi,
> >
> > attached is a new version for fusb_linux.cc.
> >
> > The current implementation uses three std::list lists for free, pending and
> > completed urbs, so submitting a single urb causes three allocs and three
> > frees
> > (pushing and popping of the list).
> >
> > The new implementation uses a circular list for the urbs, where each urb is
> > marked as free, pending or completed. As the total number of allocated urbs
> > is
> > constant, no allocs or frees are needed.
> >
> > Benchmark:
> > usrp/host/apps/test_usrp_standard_tx -B 512 -N 64 -M 128
> >
> > old code needs ~990e6 instructions, new code 690e6 instructions. The call
> > to
> > usrp_basic_tx::write goes down from 380e6 to 80e6 (so almost down to a
> > fifth
> > ...), the remaining instructions is the pattern fill for the sample buffer.
> >
> > Regards,
> >
> > Stefan
> >
> >
> Have you tested receive performance, and is it improved?
>
> Bandwidth is my dearest friend in radio astronomy (in the absence of
> RFI), so getting the best USB performance
> that's possible given CPU constraints is important to me.
>
Marcus, in my experience, USB performance has not be limited by cpu
cycles. It seems to be primarily a function of the design of the host
controller, the firmware in the device, and a reasonable way to get
the data into user mode. In most apps I've benchmarked, the overhead
of all usrp related stuff is typically on the order of 5 to 10% of the
total cycles consumed.
Eric