On 06 Oct 2015, at 16:44, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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. I changed /sys/block/<device>/device/max_sectors to 4096 and /sys/block/<device>/queue/max_sectors_kb to 2048 That improves matters slightly from 140MB/s to 160MB/s. Using Paul Zimmerman’s suggestion I can increase that to 174MB/s using a 160k buffer. However changing to a tmpfs backing file for my gadget makes no difference in speed at all. I guess that means that the delays are actually part of the gadget and/or f_mass_storage implementation. >> 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. I would be happy with anything over 300MB/s for sequential transfers. > >> 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. Couldn’t we at least use interrupts to timestamp when individual frames are sent/received or when DMA starts/completes? 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
