On Wed, Oct 12, 2011 at 4:59 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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. > (sorry for mixing 2 devices, but it's both related to bulk and transfersize, let's say Device A has the more flexible USB chipset which works by modifying the registers, Device B has the fixed bulk transfer buffer size) 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. 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 We are only using asynchronous transfers for all devices. >> 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. > > .. sorry about that.. >> > 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? > USB Transfer is related to the USB chip. The device is meant to support Windows first priority. Linux turns out to a drama again :-( >> 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 can test this with a low-end ARM System but I guess it will work since device A has proven to me that the chipset can have an effect on everything. >> 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? > yes async. Markus > 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
