On Sunday 01 July 2007, Alan Stern wrote: > On Sun, 1 Jul 2007, Oliver Neukum wrote: > > Am Sonntag, 1. Juli 2007 schrieb Matthew Dharm:
> > > Does anyone know if the SCSI core actually follows the sg_tablesize > > > parameter in the struct scsi_host_template ? Right now, it's set to > > > SG_ALL, which means "unlimited number of sg elements", but any other > > > non-zero value is supposed to be the maximum number of segments that the > > > SCSI core sends to usb-storage. > > > > It seems to me that this is the key parameter determining the throughput > > of the storage driver. > > No. Just as important as the number of sg elements is the total > transfer size. ... and the device speed. For full speed devices, at max of around 1200 bytes/frame, when the system isn't horrendously busy it might suffice to have just a few 4KB URBs queued(*) and have a completion handlers smart enough to recycle those. That is, always keep one URB in the queue, and reuse the others ... a strategy that could be implemented today in the scatterlist code, if desired. For high speed, with max of around 35 KB/frame to most commercial USB disks, queueing lots of data (== transfer size) is essential to maximizing throughput. (*) Understanding that OHCI is friendlier than UHCI in this case, another issue is interrupt rates. What OHCI does right now, at least in the scatterlist code, is to hold off URB completion IRQs for up to 7 frames. That means that a given endpoint will often have up to three "finished" URBs that haven't yet been handed back from hardware to software. All other things being equal, it's better to use two IRQs to handle six 4K URBs than use six IRQs; that's another "throughput" factor. > Since each sg element refers to a page or more of data, > the maximum number of elements is restricted by the maximum allowed > transfer size (which is currently 512 KB or 128 pages on i386). The > default max transfer size set by usb-storage is 120 KB. Larger values > would lead to larger throughput but the benefit would be slight. The relevant factor their being per-request overhead: usb-storage must send a command, transfer data, get a response; and scatterlist code only improves the "transfer data" bits. That is, it can get rid of wasted bus time between data packets ... but not wasted time surrounding the command or response. > However none of this matters if you don't insist on allocating a > separate URB for each sg element. 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. - 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
