Re: speeding up ugen by an order of magnitude.

On Wed, 7 Jul 2004, Julian Elischer wrote:

> Yes that's why I brought it up here.  That was only a "proof-of-concept"
> that showed that teh slowdown was coming from the fact that the ugen was
> only pushing one KB of data per frame (1mSec) interrupt. (it was pinned
> at 1MB/sec)  The correct answer may be to do what pould-henning
> suggested and use teh physio facility to do this. I considerred that
> originally but there is overhead in that too, and it is also possible
> that the NetBSD and FreeBSD physio facilities have diverged enough to
> make this non trivial as far as keeping diffs to a minimum. (It is after
> all NetBSD code). 

You might want to take a look at the ZERO_COPY socket send code, as well
as the sendfile() code...  FYI, I'm in the process of reformulating some
of the zero copy send code on the advice of Alan Cox to make it less
strict about alignment, etc.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Principal Research Scientist, McAfee Research


> 
> It would be possibel to modulate teh malloc per xfer by only malloccing
> a buffer large enough for the transfer, but the malloc per transfer
> seems a lot of overhead. Alternatively it may be possible to malloc once
> for every endpoint on teh client device, but I'm not clear on whether it
> is possible to have multiple outstanding requests per endpoint. If so
> then how many buffers DO we malloc, and how big? What if there are a lot
> of endpoints?
> 
> 
> > 
> > The problem is lost bus time between finishing an xfer and issuing
> > the next one - consider that part of this lost time is OS dependend
> > latency and in fact might be limited to FreeBSD.
> 
> No, the lost time is I believe due to something in the way that the ehci
> driver is setting things up. I believe from empirical evidence that 
> we are getting one transfer per frame (8 uframes). I don't believe OS
> response time is a key factor. 
> 
> 
> > 
> > What about those options:
> > - limit the allocated memory to the user request so we don't take the
> >   whole 128k if not reuired.
> 
> this requires a separate malloc per xfer. it;s a valid option but 
> is it acceptable?
> 
> 
> > - Do interleaving with 2 or more xfers if the read request is known to
> >   take more xfers.
> 
> You still need to malloc enough data for all outstanding data.
> better to do it with ONE request than multiple..
> 
> 
> > 
> > Naturally the situation with bulk writes is the same.
> 
> yes.
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>