On Sat, Dec 18, 2010 at 03:42:45PM -0500, Alan Stern wrote: > On Sat, 18 Dec 2010, pevnev@xxxxxxxx wrote: > > > Hi, > > > > I have Fedora 12 running on dual CPU (0.8 - 1.6 GHz) Intel based Lap Top with single USB port > > This USB port is directly (no USB hub) connected to FTDI's FT2232HL USB device (which is integrated into Xilinx FPGA of > > the custom board) which is continuously sending data to usb port at Lap Top at speed from 8 to 11 GByte/sec > > 8 GB/s is well beyond the capability of USB. Do you perhaps mean 8 to > 11 KB/s? > > > The application software (based on FTDI's D2XX API interface) ,which is trying to receive this data, is running on that LapTop ToughBook as a real time task. > > The FTDI's D2XX API interface supplies the call to check whether data is locally available and another call to read it out. > > Typically the data bytes are available at intervals between 3 and 20 msec but sometimes the data is absent for 120 msec and longer .. > > The USB wireshark analyzer, installed on that Lap Top, shows that data is flowing continuously > > What debugging does Linux USB interface has (as built-in) to invoke in order to see what causes such long (120 msec and longer) delays > > ? > > You can use strace to record what the application is doing. > > By the way, contrary to what Greg KH said earlier, USB is fairly > reliable for time-critical work _if_ there is only one device on the > bus. Even then, I have seen problems happen when people try to rely on that data always being sent/received within tight bounds. So it's really not safe to use USB with that type of expectation, even with a RT kernel running, as things do have a tendancy to have long delays without warnings. So I really wouldn't recommend USB for RT systems, and the RT Linux people also seem to agree based on their testing and experience (laser welding robots and the like.) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
