Re: speeding up ugen by an order of magnitude.

On Thu, Jul 08, 2004 at 10:46:51AM +0200, Bernd Walter wrote:
> On Thu, Jul 08, 2004 at 01:16:24AM -0700, Julian Elischer wrote:
> > On Wed, 7 Jul 2004, M. Warner Losh wrote:
> 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?

OK - It looks like you are absolutely right.
It seems that the controller sweeps trough the request queues on a
per frame basis - we can only get per frame what we have set.
What we havn't set at that time won't make it onto the bus until the
next frame.
Not surprising after rethinking, because the priority calculation
is done on a per frame base.

If we just have a single 1k xfer then 1k is all we can ever get per ms.
If we have two 8k xfers or a single 16k xfer then that's what we can
get per ms at maximum.
I havn't calculated the maximum size per frame yet, but if it's 60k
then we really have to push xfers for 60k into the pipe in parallel
and we are required to have setup the next xfers in time for the next
frame.

Say you are doing 128k and you get 60k per frame.
Then you get 60k in the first ms, 60k in the second and only 8k in
the third - then you setup the next one and get 60k again.
If the bus is loaded with other requests then the splitting is
different.
Interleaving two 64k requests would get us 4k of the first request and
56k of the second request during the second ms.
Well - that theoretical so far...

Can we do interleaving with physio?

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