On Tue, 6 Oct 2015, Paul Jones wrote: > 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. Or part of the hardware. > >> 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? Not individual frames; they don't generate interrupts. In fact, the computers aren't aware of them at all. They are handled entirely by the USB host controller or device controller hardware. As for DMA, you're already getting that information in the usbmon traces. (Well, almost -- the submission timestamp is created before the driver sends the transfer information to the hardware, and the completion timestamp is created after the transfer is complete and the driver has processed the completion interrupt.) 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
