Hi, > > however, what if I > > allocate > > a 128byte buffer just for the sake of this example, and submit URBs with > > 64 byte transfer buffers. > > I hope you're speaking only theoretically. A 64-byte transfer buffer is yes, of course, I'm working currently with 5 ms buffers
> > For the first bulk IN transfer, the 64 byte > > arrives > > OK, however, for the second, let's suppose that the URB returns with > > only > > 32 bytes instead of 64 (AFAIK the usb core is legitimate to do this..) > > It is. Note that in general with bulk transfers, arrival of a > short packet (32 bytes instead of 64, for example) indicates the end of a > data stream. so you mean that a short packet will only arrive if the device sends a short packet or the usb core can decide that "ok, for now I return only this much, because this much arrived till this moment"? if the latter, how is "moment" defined, end of the USB frame? Because my device sends only 64 byte packets, no short packets.. > This wouldn't happen, since the data stream ended with the 32-byte packet. > But suppose for the sake of argument that it didn't end. You still > wouldn't wrap in the middle of a packet; what would happen is that the > next transfer buffer would be at the start of the ring buffer and the next > 64 bytes of data would go there, as expected. In other words, your ring > buffer would have a 32-byte "gap" between the end of the 32-byte packet > and the start of the following 64-byte packet. yes but in this case I'll have to signal to the "consumer" that a short packet arrived and there is a gap. This complicates the algorithm somewhat :( Is there such and algorithm coded in one of the usb drivers? A simple ring buffer can be coded without locks if there is only producer/consumer, however I'm not sure about the above case.. whether locks will be necassary while doing housekeeping of ring pointers/lengths > If you think about it, it has to work this way. Since you are streaming, > you always want to have an active URB -- otherwise you lose an opportunity > to transfer data. You don't want to wait for one URB to finish before > submitting the next one. So even though URB "B" only transfers 32 bytes, > you must submit URB "C" before "B" completes, before you know that it will > get a short packet. Hence you must assume that "B" will transfer the full > 64 bytes and leave that much space in the buffer. yes true, I cannot argue.. > > Or maybe you start over at the beginning of the > > ring buffer > > where there is enough space? > > (suppose the user already read and removed the first 64 byte packet from > > the buffer by that time) > > If you're doing this right then URB "C" has already been submitted, with > its transfer address at the start of the ring buffer, and it's too late to > change that. yes, you are right again.. What I'll do probably is to segment the buffer into slots, and I'll have an int for each slot, containing the number of bytes received in that slot. By the way, how do you decide on the URB's length? Obviously, the bigger the length, the more delay my PC-side application will suffer, but the more efficient the transfer will be. However if I go down to 64 byte URBs, delay will be very low, but the completion handler will be called more often.. or it is not so severe? The smallest chunk of data my application can use is around 5ms or 640 bytes (the device sending 64byte packets), while the maximum delay I could tolerate is around 20ms , which comes down to 2560 bytes. Is there any reason not to stick to 640 byte URBs? Thank you for Your answers, they are just invaluable for me as a beginner kernel driver programmer! Regards, Istvan ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
