On Wed, 12 Oct 2011, Markus Rechberger wrote: > ok here you must miss something with your explanation or bulk analysis. > The effect is, if the device is set up to low transfer buffer -> high > cpu load, if it is set to > bigger transfer buffer low cpu load. We are talking about 30% CPU > difference on 1.3 ghz. I don't see why the size of the transfer buffer should have much impact on the CPU load. The CPU has to do about the same amount of work per data byte, regardless of how those bytes are grouped into buffers, right? One of the main factors affecting CPU load is how frequently interrupts occur. If you use small buffer sizes and get interrupted after each buffer is filled, the overhead will be higher. But you can avoid that by making the interrupts occur less often: Set the USBDEVFS_URB_NO_INTERRUPT flag for most of the transfers. > It does not matter what transfer buffer size the userspace application > is set to. > > According to the specs: > Available Bulk Transfer Size are: > - 188*n bytes, where n = 1~256 How are these bulk transfers divided into packets? Is a single transfer of 188*n bytes divided up into 188*n/512 packets, each holding 512 bytes, plus a possible shorter packet at the end? Or is it divided into n packets, each holding 188 bytes (which would be much less efficient)? > We are only using asynchronous transfers for all devices. If you can arrange a static image, so that the data bytes don't change between frames, it would be worthwhile comparing the data you get with the various transfer schemes. An easy way to do this is to use Wireshark to capture the transfers. Also, it might help if you post a sample of the code you are testing. Maybe something will stand out. 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
