On Sat, 17 Oct 2015, Paul Jones wrote: > On 17 Oct 2015, at 12:30, Alan Stern <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
