On May 26, 2016, at 1:57 PM, Antonio PĂ©rez <ape...@skarcha.com> wrote: > > I downloaded the code and patched and compiled myself. Using some > "sleeps" it goes better, but not so fine I would like: > > %<------------%<------------%<------------%<------------ > write(2, "send: QS\n", 9) = 9 > nanosleep({0, 100000000}, NULL) = 0 > ioctl(4, USBDEVFS_SUBMITURB, 0x7ffc0d2c66e0) = 0 > ioctl(4, USBDEVFS_REAPURBNDELAY, 0x7ffc0d2c66a8) = -1 EAGAIN (Resource > temporarily unavailable) > select(5, NULL, [4], NULL, {0, 1000}) = 1 (out [4], left {0, 564})
How would you improve it? There will definitely be a tradeoff between responsiveness and CPU usage. I CC'd the author of nutdrv_qx - I think it could work to add a "usleep" corresponding to the approximate size of the sent and expected receive packet, but this would be different for 1.5 Mb/s and 12 Mb/s USB devices. You might also want to add timing numbers to the strace output (either "-tt" or "-T"). > Is this the right behaviour? If not, could it goes better using > libusb-1.0? Are the port to libusb-1.0 in the roadmap? So far, there have not been any good arguments for libusb-1.0 that would offset the amount of testing needed. Feel free to experiment, though. For timing purposes, it should be sufficient to write a small loop that sends the command for your UPS, and reads the response via libusb-1.0 (rather than trying to port the entire NUT driver). -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev