There is no guaranteed minimum latency for usb per se, but there is a 1 msec quantization for receiving data from a USB device. The latency for just sending to it is dependent on the current processing load of the usb port (number/size of outstanding data transfers) and the os usb scheduler.
The usb host controller typically operates on a 1 msec usb cycle period. Any data that comes in from a usb device will only be detected and returned to your application at the boundaries between such 1 msec cycles. You have effectively 1 kHz sampling frequency.
A "blocking" write, e.g., via a usb-serial port and our IOPort driver will quantize to this 1 msec cycle, because it consists of sending data to the device and then waiting for an acknowledgement from the device that data has been received/processed there - the perceived delay for such a write is up to 2 msecs typically. Best case: Blocking write happens shortly before the end of a usb controller cycle, gets transmitted to device, immediately acknowledged before reaching the end of the 1 msec cycle and picked up by the operating system: You'll see < 1 msec delay. Worse case: Write happens before the end of the 1 msec cycle, but acknowledgement from the device only is reached after crossing the border to the next 1 msec cycle. Then the app will only see the end of the write after the end of this 2nd cycle -> 2 msecs delay. Worst case: The os or usb port is heavily loaded/overloaded and the whole procedure can delay over multiple cycles, possibly hundreds of milliseconds.
On average you'll observe 1-2 msecs for blocking writes on typical systems and configurations.
A non-blocking write will just send the data to the usb host controller. It won't wait for any acknowledge from the device, so it will return almost immediately. The actual data transfer happens as soon as the usb port has free transfer capacity. This can be as low as 100 microseconds on an otherwise idle port and system, or dozens of msecs. But typically you'll see no more than 1 msec delay.
There are also different types of usb transfers with different priorities and the most common bulk transfers (e.g., for ftdi serial port / com port drivers and similar) are lowest priority. But most other transfer types are not supported by such devices.
If you only want to read data, e.g., button responses, input ttl triggers, you'll observe the 1 msec quantization of the usb duty cycle.
In the end, practical experience shows you can get approx. 1 msec delays for non-blocking operations, e.g., by using typical usb-serial converters or the beloved Bitwhacker, which emulates a ftdi serial port device. But there aren't any guarantees for worst case latency.
Oh and most serial port converters don't send data immediately, but in bursts, to reduce overall system load. FTDI's pieces allow to select the latency between 1 msec and something much larger. They default to 16 msecs granularity iirc.
We do use the bitwhacker and properly configured ftdi serial port converters to send or receive triggers, as the 1-2 msecs latency is usually good enough for us. And the bitwhacker is nice as a parallel port surrogate as it has up to 78 digital i/o pins and only costs some 40$ or so.
Oh and the way to get guaranteed timing is usb interrupt transfers - guaranteed to run periodically at up to 1 msec period (this is what is used to poll mice and keyboards at precise 8msecs intervals) and usb isochronous transfers (used by things like usb audio or video). But both are usually inaccessible for the kind of apps you want, unless you feel like writing your own operating system kernel device drivers.
My memory of this is a bit shady, so i may have forgotten to mention some details. Also i simplified a few aspects.
-mario
--- In psychtoolbox@yahoogroups.com, "mlrogers2002" <mlrogers2002@...> wrote:
> Hmmm...
>
> So you must be using the FTDI Virtual Com Port driver, and just writing to the virtual com port directly. From what I gather, the USB scheduler has a latency of order ~1ms (but maybe this is a Windows number), so repeated calls coming out at ~400µs intervals is right in the range one would expect if that really is the normal latency of USB calls. I think it all boils down to the latency of the USB scheduler. Once the FTDI picks it up and sends it to the pins, it should seem instantaneous when looking at times in the scale of a ms (i.e. eternity in terms of FTDI clock cycles).
>
> I made an adapter once before using the FTDI 245 R in Bit-Bang mode (actually, I think it was a DLP USB-245M, but the 245R looks like the thing to get nowadays) or something very closely related, but I never measured the timing since it did what I needed it to do. I think I'll just make another one (they're $20 or so from Digi-Key), and write a little wrapper in C to send a single byte to the pins, which I can call from octave.
>
> I would have to solder up a DB25plug anyway to talk to the BioSemi EEG box, no matter what hardware I use to get the signal out of PTB- why not just buy the cheap and simple solution? In fact, if this is satisfactory, then everyone who has this problem can make one (and I'm not the first person on here trying to send triggers to a BioSemi box with PTB and no parallel port).
>
>
>
> --- In psychtoolbox@yahoogroups.com, "IanA" <iandol@> wrote:
> >
> > --- In psychtoolbox@yahoogroups.com, "mlrogers2002" <mlrogers2002@> wrote:
> > > Does someone know (roughly) the latency on sending TTL triggers (8 pins at once) to the USB-1208FS or one of its relatives from a modern Mac using DaqDOut(...)? (modern at the time of this posting comes from the Apple Store with OS X 10.6.4)?
> >
> > Well, I haven't tried with the measurement computing device, but I have tried with an FTDI USB->Serial adapter and PTB IOPort command, and if I toggle it low>high>low a 1000 times I get an inter-switch interval of 0.4ms (and the standard deviation is low), and an assumed latency of only somewhat higher for single switches (screen flips every refresh measured with a photodiode)
> >
> > I have also adapted the wonderful LabJack U3 (by far the nicest Mac USB DAQ device on the market) to work in OS X Matlab, and I get an inter-switch interval somewhat higher with a slightly higher variance. I'm currently writing a class to wrap around it and running into a couple of crashing bugs, but once finished I'd be happy to share that with the group.
> >
> > Ian
> >
>