Re: speeding up ugen by an order of magnitude.

On Thu, Jul 08, 2004 at 01:16:24AM -0700, Julian Elischer wrote:
> 
> 
> On Wed, 7 Jul 2004, M. Warner Losh wrote:
> 
> > In message: <Pine.BSF.4.21.0407071137440.80217-100000_at_InterJet.elischer.org>
> >             Julian Elischer <julian_at_elischer.org> writes:
> > : > Nevertheless I see ugen more as a quick and dirty way to test drive a
> > : > device from userland with all it's great debugging capabilities before
> > : > writing a specific kernel driver.
> > : > The requirement that ugen has to be generic is often bad for
> > : > performance sensitive applications.
> > : 
> > : Ugen is used in production all over the place where people have to used
> > : devices there is no specific support for, and where there is no
> > : kernel expertise.
> > 
> > usb drivers are very easy to write.  I think that making it easier to
> > write those drivers is going to be better for the project in the long
> > run.
> > 
> > ugen is supposed to be general.  If we can make it faster w/o
> > sacrificying this generalness, that's OK.  But if we can't, then you
> > gotta do stuff in the kernel.  That's always been the case (and why we
> > don't have userland tcp, for example).  Some things have to be in the
> > kernel to be fast.
> 
> I don't think this has to sacrifice generalness..
> 
> Matt Dillon just made a simple patch for this on Dfly and I'm looking at
> back-porting it. there is nothing in ugen that shouldn't let it take
> data from a bulk USB2 device at a good speed except that it doesn't ask

There are technical limits - such as that we can't support select and
prereads without breaking generalness for bulk endpoints.

> for the data that fast.. it is possible that there is a problem in the
> ehci driver too, but I haven't got my mind around that driver quite
> fully enough yet to say for sure.. it looks like it doesn't allow more
> than one transfer per msec frame from the ugen device.  solving this

Possibly a side effect because we have to disconnect the pipe queue to
modify it, but I still think its the time we need to take the completed
xfer and setting up the next one.

> would allow the use of smaller buffers. I don;t think it's a problem
> woth overhead and small transfers, but rather that ugen is asking for
> only 1 x 1KB transaction per mSec when USB2 is capable of delivering
> 60KB/mSec. I think increasing the buffer size means still asking for one
> transaction per mSec, but it's a bigger transaction :-)

What interrupt rate do you see from the host controller?

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd_at_bwct.de                                  info_at_bwct.de