On Wed, 6 Nov 2002, Boris Dainson wrote: >I got video capture running so iso pipe with multiple IRP submissions is >working well! Some video frames are messed up but it looks like this has >to be settled between the chip and the application. The leak is still >there as I wrote before though.
I'll make sure to look for it. >I also ran device without activation of the iso pipe with an infinite >loop of syncSubmit to a control pipe. It's quite stable: no exceptions, >no hangs. However it's leaking 150-200 bytes per submission. GC shows a >clear growth of allocated memory, eventually an OutOfMemoryError is >thrown. RI from the last year was not leaking under normal conditions. > >Another problem with the control pipe is that it takes 9-12 ms for >syncSubmit call to return. Compare this to 2-4 ms for the Windows driver It will probably be hard to reduce that latency, but it might be possible. I think that most or all of it is in either the kernel itself, or the sleep() call. I'm hoping to get rid of the sleep() polling, but haven't yet. I'm assuming you have a UHCI hardware Host Controller; if so, have you tried both the usb-uhci and uhci kernel drivers? One may be faster... >(probably 3 ms or less on average). It's quite important for applications >that use control pipe a lot: I2C read is 4 syncSubmit calls so it'll take >a second to get a telemetry packet of 20 bytes. I don't know how to use >composite IRPs with asyncSubmit since you have to alternate reads and >writes on the control pipe with program logic in the middle that depends >on results of these reads (checking for I2C ready). yeah, that's not possible (now). The list has to be basically fixed-data. I think it would be harder than it's worth to do dynamic-data submission, where one data packet depends on the previous results...it's easier just to let the user parse and submit another... as far as your time calculations, are you sure than 4 syncSubmits (assuming they are 12ms) adds up to 1 second...? Isn't 4*12ms = 48ms? I agree that if Windows is 3ms, 4*3ms = 12ms which is much better, but still 50ms is pretty fast...at least, fast enough for now...? Does your application see performance problems because of it? Thanks! -- Dan Streetman [EMAIL PROTECTED] --------------------- 186,272 miles per second: It isn't just a good idea, it's the law! ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ javax-usb-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
