John Youn <John.Youn@xxxxxxxxxxxx> writes: > Hi Paul, > > Good to see you're still hanging around. > > On 10/5/2015 3:38 PM, Paul Zimmerman wrote: >> On Mon, 5 Oct 2015, Alan Stern wrote: >>> On Mon, 5 Oct 2015, Paul Jones wrote: >>> >>>>> 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. >>> >>> That's a decrease, not an increase. Try changing it to 1024 or more. >>> >>>> 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. >>> >>> The dd block size makes no difference at all, because the kernel >>> aggregates the requests from dd. >> >> In my experience, you need to do at least the following to get max >> performance from the mass storage gadget: >> >> - Use Windows 8 or higher on the host. It's much faster than Linux. >> - Put the backing file for the mass storage gadget on a tmpfs. >> - Increase FSG_BUFLEN (in > > Speaking of which... > > I found this old patch to set the FSG_BUFLEN. Any idea why it never > got merged? because I ended up never refreshing it :-p There was suggestion to make it a module parameter, instead of compile-time choice. -- balbi
Attachment:
signature.asc
Description: PGP signature
