On Monday 02 July 2007, Oliver Neukum wrote: > Am Montag, 2. Juli 2007 schrieb Alan Stern: > > On Mon, 2 Jul 2007, Oliver Neukum wrote: > > > > > Am Montag, 2. Juli 2007 schrieb Alan Stern: > > > > > As noted above, for full speed devices we could get similar throughput > > > > > with slightly more clever implementation of scatterlist handling. If > > > > > the HCD has good hardware support for queueing, and the system has > > > > > fair > > > > > IRQ latency, recycling as few as five URBs might give similar > > > > > throughput > > > > > to the current "URB per element" approach. > > > > > > > > I think we definitely should do this. For high speed the advantages > > > > aren't so great, since the amount of data needed to fill the pipeline > > > > is about the same as the default max transfer size anyway. > > > > > > Doesn't this boil down to using CPU cycles to save memory? > > > Even worse, many of these cycles would be used in interrupt context. > > > > I don't think so. For one thing, we'd be allocating fewer URBs. For > > another, the total number of submissions would be the same; they would > > just be spread out in time instead of all at once. > > But the number of interrupts would grow. The ideal number of interrupts > per transfer is 1. If you can avoid using more by using a bit more > memory, is a winning strategy.
And if you don't have the memory to spend, then you spend the IRQ. No worries, it all works fine. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
