Need help, Delay Battle: USB vs LPT vs PS/2

[DJKero]

I want to know if someone knows, which interface is the one that haves faster response for connecting PS2 Controllers to PC...

A friend said always that LPT was the best interface, but another friend today said that there are a USB Adaptors that are used on Evolution Championship Series...

My issue is that I need to have the lower delay possible because I use a PS2 controller interface for a Rhythm Game Controller... which needs to be reallly accurate, if can't be no-delay between MicroSwitches and PC...

Thanks for the help

[adder]

i dont have any lags with my venom ps2 usb converter
however, these are hard to find now. check ebay and amazon etc

[RandyT]

I don't know how far apart the control events are spaced, but you may want to be careful with USB.  If events are within a fraction of timing of each other, and they go out in the same report, there is no guaranteed order of those events when they are processed by the system.  We are talking very small increments of time, so it may be ok for your application.  But if you need a true FIFO arrangement, you won't find it with USB.

[MonMotha]

OTOH, it's possible to get the latency lower on USB than PS/2, amusingly.  The reason is that PS/2 has to serially clock bits into the PC at a rather slow rate, then you get a "hard" interrupt.  USB interrupts are polled (by hardware) at some fixed rate, but the bit rate used for data transfer is much higher: so much higher that it, if you crank the interrupt endpolling polling rate all the way up (1kHz for FS devices), it can actually take longer to clock the bits across the PS/2 port for some events than it takes to for a worst-case poll delay on USB (which then transfers the entire state of the device over).  This gets even worse if you have multiple "simultaneous" events: PS/2 has to send them all in sequence while USB can report them all at once.  HS (480Mbps) USB devices can actually do even better: their poll rate can practically be several kHz, and there's plenty of bandwidth to back it up.  This tends to be useless for HID devices, though.

Of course, as Randy says, if you absolutely need true FIFO style strict ordering, USB HID cannot guarantee it, though there's no reason you can't use a vendor- or application-specific USB protocol to get it.

A real parallel port in general provides the lowest possible latency.  The IRQ on that thing really is wired straight up to the old ISA interrupt controller.  Depending on the system, getting a real CPU interrupt out of this may take some time, but it's usually well less than 1ms.  You can then read the data lines on the parallel port with very low latency (just enough time to cycle the ISA/LPC bus), though note that reading the status of a Playstation controller takes several cycles of the parallel port and may in fact be slower than having a dedicated microcontroller on e.g. USB handle it - it'll certainly have more CPU overhead.

Now, at this point, we're down to where we need to mention one other thing: the scheduler tick of most modern OSes is, at fastest, 1ms.  I think Windows still uses to 10ms as of XP but may be faster on Vista/7/8.  HZ on Linux is configurable at kernel compile time and was historically 100 (10ms) but is now usually 1000 (1ms).  In general, this means that, in a contended multitasking environment, you cannot expect to get less than 1 or 10ms of latency to a user-space application.  Playing some tricks with priority, writing the application properly, and having a very lightly loaded system can sometimes get you into something looking more like async behavior, but it's tough to make that guarantee on any general-purpose (non-real-time) OS like Windows, Linux, BSD, OSX, etc.

[RandyT]

Yes, my comment was not meant to be an indictment of USB.  One can do pretty much anything, with proper firmware and host driver support.  It was meant in the context of the converters, shown in a couple of posts up, as these are usually HID devices.  Of course there's a whole other level of data massaging in those boxes as well, with their own latencies, event ordering, etc...  This brings me to something else I thought was somewhat amusing;  not too long ago I watched a video where someone meticulously set up a test to have a single button connected to two different controllers (not one of ours) attempting to find out which had less lag in getting the event to the PC.  The results favored one fairly often, but not always.  Of course each controller was connected to a different USB port on the system.  This really demonstrates what I was referring to.  If one controller was faster than the other, even by a tiny bit, and the PC handled the events strictly in a FIFO arrangement (nearly impossible on the processing side across two different ports) then the faster controller would always, and without exception, be processed first.  This, of course, didn't happen and the "tester" didn't seem to bother swapping ports and conducting the same tests for comparison.

FIFO is important for applications like gameshow buzzers, and possibly fighting games.  If two players are executing moves at essentially the same time, and one move counters the other, the one which takes precedent is not always the one which happened first with straight HID.  As MonMotha pointed out, however, the faster the polling, the lower the likelihood that the two moves will end up in the same report, thereby negating this effect.