Re: [libusb] libusb_bulk_transfer: non-deterministic transmit latency on Linux 2.6.32

[michel <dia...@ya...>]

I also think it is user space scheduling issue 
by default HZ sys tick is 100 => 10ms so unless your system is 4 processor
you can easily have 10ms+ task scheduling delay if the threads don't block
and do some processing in between packet send/rcv.

also i guess even on linux libusb create a thread for the synchronous
operation so it's one more thread to take into account.


in similar use case (bulk in/out) win7 many  thread using out 1 thread in 
all  doing synch i/o (>=100ms  time out) i get 125 us to 350 us round trip
time on bus (data from host to device , data back from device to host)  but
i never measured tx to rx effective delay at thread level.

best option is like usgested already to use a synch transfer ,
that will not guarantee you'll get packet callback i very short time <10ms 
but at least that you'll get smallest latency and best possible delay on
request submission to bus handling. The user space handlinf delay  is yet
under the kernel controle and fully non determinsitic 


Somehow depending on your s/w architecture and system h/w and load  you
can't guarantee anything  at user level using bulk , even in interrupt if
you're not able to sustain and keep feeding and  pumping data at  the ep
interrupt interval  that can be as low as 1ms F/S 125us h/s .  than mean
assync and quiet a lot of flying xfer. 




--
View this message in context: http://libusb.6.n5.nabble.com/libusb-libusb-bulk-transfer-non-deterministic-transmit-latency-on-Linux-2-6-32-tp5714809p5714811.html
Sent from the LibUSB Dev mailing list archive at Nabble.com.