On Thu, October 4, 2007 12:00, Oliver Neukum wrote: > Am Donnerstag 04 Oktober 2007 schrieb Indan Zupancic: >> E.g. some mechanism where the buffer size and buffer count is chosen >> dynamically depending on how fast the device turns out to be, and some >> latency constraints. For number of buffers it's easy to do, e.g. new buffers >> could be allocated up to nr_bufs_in_flight * 2. Doing the buffer sizes > > How do you define "in flight"? You can submit any number of URBs > to which buffers correspond. You'd have to measure the actual throughput. "in flight" are all submitted URBs. But what's actually wanted is the number that makes sense to have in flight, as far as bandwidth goes. The factor 2 is to catch bursty submissions, but it should probably be lower. Yes, you're right it's more complex than that. If throughput is measured new buffers can be allocated up to the point the throughput doesn't increase anymore, with some sanity boundaries (both size and latency I suppose). Measuring throughput can be done by checking a timestamp at URB callback. Another way would be to only check the time interval between the URB callback calls and use that to guess if the device could use more URBs or not (rationale: as long as the interval decreases when adding URBs, there's spare bandwidth left). Packets can have different sizes, so this might not always work well. Greetings, Indan
