Hi, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Fri, 9 Oct 2015, Felipe Balbi wrote: > >> that's all clear :-) The point is that I _do_ get a ton of PINGs because >> the gadget doesn't queue requests fast enough and I'm, currently, >> blaming the latency of the kthread() itself, though I haven't been >> successful at proving that statement thus far. > > Do you get similar PINGs between buffers? Unless you've changed from > the default, each buffer is 16 KB so delays would show up at intervals > of 32 bulk packets. yeah, I'll check that tomorrow if I get some time. Dealing with some other silicon "problem" right now. Patches might show up soon(-ish) > If you do see a lot of them, it means that either the data rate from > the backing file is slower than the USB transfer rate or that I'm using RAM as backing store for all my throughput measurements. > usb_request submission overhead is taking too much time. You can test > this by increasing FSG_BUFSIZE in storage_common.h and seeing if the > behavior changes. right, at some point I was using 32 usb_request with up to 64kiB buffers, queueing as much as possible to UDC and interrupting after each one of these requests (so giving back as soon as one of the up-to 64kiB request completed) > If you don't see them, it means that initial scheduling of the kthread > takes too long, as you guessed. But this doesn't say why scheduling of > the kthread between buffers is quick. One possible reason would be > that the rates are so well matched that each time the kthread wants to > fill a new buffer, one of the in-flight buffers has completed and is > available for re-use. that could very well be it, considering I'm running on UP, it could just be luck (or lack thereof). -- balbi
Attachment:
signature.asc
Description: PGP signature
