Charles Chen wrote:
50 may be overkill, but why do you think increasing the queue size is
"not
a good work around"?
My guess is increasing the queue size only postpone the occurrence of
the data missing between irp groups, rather than totally eliminate it.
50*20 irp lasts for one second. so it is good now for 2-second
recording. I am not sure if it will be good for longer recording. I want
to know under what circumstances data will be missing between the irp
groups, and hope to have a real solution for that.
The irps acts as a buffer, and you will probably be missing data
whenever the buffer is full (there are no submitted irps waiting to get
filled with data). So, what are the scenarios where you will not be able
to submit IRP's fast enough?
1. If you can't process the data faster than it is generated. (Probably
not an issue, I generate images from a video feed on my 2.4 GHz computer
and that takes ~2% CPU time, but displaying it makes X take another 10-15%).
2. The kernel will not fill the buffers in a timely manner. I don't
think this is an issue either.
3. You get a GC which stalls your program. This can be analyzed further
by enabling verbose GC.
4. The OS swaps your program, does not schedule it for running etc.
Usually not a problem on Lunux or a modern Windows.
There are also some quirks in the code that can be good to be aware of.
The moving of data from kernel mode buffers to java byte[] is not done
every ms, but instead 20 buffers are filled every 20ms (due to the
issues with scheduling use mode code to run every ms). Therefore I think
it would be good to have more than 2 20irp buffers, so there is always 1
extra buffer waiting if the irp's are not exactly synchronized with the
clock.
I'll try to run my code again this weekend and see what rates I get, I
seem to recall that I get very close to a 100% utilized bus. (The video
protocol includes at least one empty usb packet between each video frame
and I'll have to check if I counted that in my statistics.)
//Roger
-------------------------------------------------------
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
_______________________________________________
javax-usb-devel mailing list
javax-usb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
