Bert Vermeulen wrote: > However, this will in no way fix that problem with the FX2s. The root > of the problem there is sending 24MB/s across a USB bus with only the > barest minimum of transmit buffers. Receiving it all in a separate > thread -- with some OS-level higher priority if we can help it -- > will help matters along, but: > > - the FX2 still isn't the only thing on the bus: other devices doing > a transfer will use up throughput capacity on the USB bus. > - sigrok is still not the only process on the system. A high > priority thread does not a real-time system make.
You actually just need to make sure to have enough pending USB transfers submitted via libusb to cover whatever period of time you want to cover without requiring to be scheduled. The queue of pending transfers goes all the way down to the USB host controller which unlike software has quite reliable scheduling and is dedicated to USB, so it just works. Remember to increase timeout of the later transfers. It may also be neccessary to cancel lots of pending transfers with this setup. There's no big problem with that either. There is a race between successful cancel and the transfer already having been scheduled on the bus, but the transfer callback can always determine which of the two has happened for every transfer. //Peter ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
