On Tuesday 24 February 2009 16:03:05 Marcus D. Leech wrote:
> Have you tested receive performance, and is it improved?
Hm, if you are going for high bandwidth, you should set the blocksize quite
high (eg 4096). I am targetting low latency, so I go for the smallest possible
blocksize (512).
If y
Eric Blossom wrote:
On Tue, Feb 24, 2009 at 01:07:34PM -0500, Marcus D. Leech wrote:
Eric Blossom wrote:
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 reaso
On Tue, Feb 24, 2009 at 01:07:34PM -0500, Marcus D. Leech wrote:
> Eric Blossom wrote:
> > 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
Eric Blossom wrote:
> 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 ove
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 alloc
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 implemen