On Sat, 17 Oct 2015, Paul Jones wrote: > On 17 Oct 2015, at 12:30, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > Paul, can you tell your email client to wrap lines after 72 columns or > > so? It would make replying a lot easier… > Mac Mail is not very friendly in this respect, but I can pay attention to > not make long lines :) Thanks. > >>> One thing you did not show here was the delay between sending the last > >>> data buffer of one command and sending the first data buffer of the > >>> next command. That overhead could significantly affect the overall > >>> throughput. > >> The next read command is generally handled within 20us after the previous one. What counts is not the time between the commands, but rather the time spent finishing up one command and then waiting for and starting the next. See below. > I’ve included a new log showing two full requests: ... I cut out the log. The interesting part is delay between the start_dma call for the CSW and the start_dma for the first data transfer in the second READ command. If max_sectors were larger then this delay would not be present at all. In the log, the two start_dma lines occur at timestamps 214.988590 and 214.988767. This is a 177-us delay -- not 20 us -- and it starts after about 850 us have elapsed. That's a noticeable amount of overhead; it means that increasing max_sectors can raise the overall throughput by up to 20%. > I did some testing using gadget zero and max out at 166 MB/s. > The big question is why the hardware won’t go any faster than that. > I am wondering whether it has something to do with the fact that the > internal FIFO size for each endpoint is currently set to 1k. The FIFO size is 1024 because that is the length of a bulk packet in USB-3. To find out what the hardware is doing, you really need to use a bus analyzer. On the other hand, I think we have adequately answered the questiona you originally raised at the start of this email thread. 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
