On Fri, 22 Jul 2011, Daniele Capuano wrote: > My host continuously receives and, when no packets are actually > received, it goes on submitting requests and executing completion > handlers in which void packets are found. Be careful. There's a difference between receiving a packet with no data and not receiving a packet at all. You can tell which happened by looking at the usb_iso_packet_descriptor's status field; if the status is 0 then a packet was received. > This happens in the normal > execution as well: if "holes" are present within the transfers, the > host simply loops and submits new requests. I tryed to avoid such > holes to appear, but in order to do that I had to setup the interval > value to 64 in the urbs submitted by the host. In this way, no holes > appear but a big amount of data is buffered: in fact, when the gadget > stops sending data, several seconds (often minutes) are needed for all > data to be actually received, that is, host and gadget go on > submitting urbs and executing completion handlers with actual_length > > 0. You're not doing this right. You shouldn't be using a single URB; you should submit multiple URBs and resubmit each one when it completes. That way the host will never be in a situation where the transfer queue is empty. (Although this doesn't seem to be a problem for you.) The size of each URB is up to you; it will depend on your latency requirements. The number of URBs should be large enough to fill the transfer queue for at least 10 ms; 20 ms would be preferable. > I supposed that an excessive amount of buffered data could cause > problems to the gadget, due to its limited resources. > Therefore I'm trying to reduce the interval to 16, and now the > communication doesn't break, but the host executes completion handlers > where data is not all included. For example: in a single urb, 2 > packets should be normally included, but the host shows some > completion handlers where just 1 packet or none is received. > > I paste here a little portion of the usbmon output: The usbmon trace shows you are transferring 512 bytes every 16 uframes. You could reduce the interval to 8 or even to 1 if it would help. > ca32bd80 1397302852 C Zi:4:015:2 0:16:4672:0 2 0:0:0 0:512:512 512 = > f8fefcfe eafef0fe fefe0e00 3800fafe 02001200 0e000800 f8fe0400 > e0fe0000 Yes, this shows the first packet contained no data and the second contained 512 bytes. > As you can see, some callbacks contain both packets of zero length. > How can I see if data is actually being lost or it's just received in > successive calls? The host won't lose data. The gadget might, or it might delay some data. The only way to tell is to look at the data values and compare them to what you would expect. > This solution could work well since the latency and the buffered data > now seem to be almost zero, but an excessive amount of lost data could > be not tolerable... You might add some debugging statements to your gadget code. Maybe it simply isn't able to produce the data fast enough -- though as far as I know, a gadget's UDC will never send a 0-length isochronous data packet if the gadget driver doesn't ask it to. 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
