On Tue, 6 Oct 2015, Paul Jones wrote: > 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? Yes, there is. I forgot about this hard limit. I think you can change it by writing to /sys/bus/usb/devices/.../max_sectors, where ... is the path for the mass-storage interface of your device. If that doesn't work, you can try editing the kernel source file drivers/usb/storage/scsiglue.c and increasing the value of the .max_sectors field in the definition of usb_stor_host_template. > >> 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. That's what I meant -- the dd block size won't affect the transfer 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. All those things take time. No doubt some of the delay is the time required to read the data from the backing file. Most of the rest is transmission time. Note that you can never actually attain 5 Gb/s, even under the best circumstances. For one thing, data on the USB bus is encoded in a way that uses 10 bits on the bus to send 8 bits of data. So you could never achieve more than 500 MB/s even if there were no packet headers, breaks between packets, and so on. > Is there a way to trace the USB frames to see where the delays are > occurring during the actual data transfer? Sure, if you have a USB bus analyzer. There's no way to do it in software alone. Alan Stern -- 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
