On 05 Oct 2015, at 20:54, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 5 Oct 2015, Paul Jones wrote: > >>> g_mass_storage, by default, uses 2 struct usb_request, try increasing that to 4 >>> (can be done from make menuconfig itself) and see if anything changes. >> If you are talking about the �number of storage pipeline buffers� I already have them at 4. >> I had similar results in previous kernels where I hadn�t set this value to 4. > > My feeling is that the number of buffers won't make a whole lot of > difference to the final throughput. Increasing the number will smooth > out variations and remove latencies caused by other tasks. But the two > fundamental limits on the throughput are the USB data transfer rate and > the rate at which data can be transferred to/from the backing storage. > Whichever is slower will be the bottleneck, and using more buffers > won't change that. > > Increasing the max_sectors_kb value, on the other hand, might remove > overhead by allowing a higher percentage of the transfer to consist of > real data as opposed to CBW and CSW packets. This depends to some > extent on other factors (such as whether the memory pages are > contiguous, allowing for larger transfers), but it can't hurt. I tried changing the max_sectors_kb to 64 with 64k block size in dd and it’s transferring at the same speed. I verified using usbmon and it then indeed requests 64k in each request. Increasing the dd block size to 240k doesn’t change the transfer speed either, and it keeps using alternating 120k/8k requests. Increasing the dd block size to 1M doesn’t change the transfer speed either, although I get sequences of 2x 120k followed by 1x 16k requests. Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
