On Wed, 12 Oct 2011, Markus Rechberger wrote: > > But it's > > important to keep in mind that the device is completely unaware of the > > transfer size. �All it sees are individual packets (and the time delays > > between them). > > > > how sure are you about that one? Completely certain. The transfer size is sort of a contract between your program and the kernel. The device isn't involved. The data you submit/request gets broken up into packets, and those packets travel across the USB bus. The only significance of the transfer size is that it controls the number of packets that get sent/received, and when they get sent/received. For example, if you submit three transfers, each for 1024 bytes, then the kernel will break each transfer up into two 512-byte packets, for a total of 6 packets. It will notify your program that the first transfer is complete after packets 1 and 2 have been transmitted, that the second transfer is complete after packets 3 and 4 have been transmitted, and that the third transfer is complete after packets 5 and 6 have been transmitted. Conversely, suppose you submit two transfers, each for 1536 bytes (but containing the same data as before). The kernel will package each transfer into three 512-byte packets, for a total of 6 packets -- and each packet will be exactly the same as in the previous case! The kernel will notify your program that the first transfer is complete after packets 1, 2, and 3 have been transmitted, and that the second transfer is complete after packets 4, 5, and 6 have been transmitted. As you can see, the main difference between the two cases is when your program gets notified. As far as the device is concerned there is no difference -- unless your program has a time delay between submissions (which will always be true if you use the synchronous API). Then the in the first case, the device will see a delay after packets 2 and 4, whereas in the second case, the device will see a delay after packet 3. > I thought the same but one of our devices > has specific registers for the USB transfer size, up to 256*188 (which > is 48128 or 94 512 bytes bulk buffers. No. The documentation for your device may call these registers "USB transfer size", but it means something different from what we have been talking about. I don't know what those specific registers do because I haven't seen your documentation. > If we do not modify that one the CPU load is very high with Linux, > also with MacOSX. This makes no sense. CPU load varies according to what your program is doing, not according to what is happening on some remote device. > The only drawback we have with small bulk values with linux is that > the CPU usage is very high. > (this is about another device). Please talk about only one device at a time. > > Maybe with further testing you can characterize the device's behavior > > properly. �For example, does it require a certain minimum delay time > > between 24064-byte tranfers? �What is its overall data rate (this > > determines the maximum delay time)? > > > > I think that would be some question for the IC design house but we are not > going to get the full details of everything as we only design the device itself. How can you design the device if you don't understand how its parts work? > There should be a certain reason why everything else than 24064 fails and the > windows driver from the chip vendor also uses that size. > > Can't we just increase the buffer to get this work with linux, everything else > seems to be really hackish.. To me, what seems really hackish is using magic numbers like 24064 without understanding why they are needed or what they really do. A simple "It only works with that number" doesn't explain anything -- for all you know, on a faster (or slower) computer it might _not_ work with that number! > I just don't have any confidence that it will work out with those > suggestions since I > tried several days last week with Linux and MacOSX until I was told to > use the other > packet size this week. To repeat my earlier question: Did you use the async API for the 11776/12288 pairs? 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
