On 05 Oct 2015, at 23:09, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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 can’t increase the value, any value over 120 is rejected. I therefore decided to see if the speed would decrease by decreasing the block size, which doesn’t seem to be the case. Is there a setting somewhere that limits the max_sectors_kb value? > >> 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. Well given the results I am getting it seems to make some difference, although it does not seem to impact speed. In my current setup I have 35us overhead for responding to the CBW and CSW requests (70 us total) and there seems to be some delay in the bulk transmission of the data as well as the transmission time for the data is much slower than 5Gb/s. Is there a way to trace the USB frames to see where the delays are occurring during the actual data transfer? 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
