Main > Main Forum
Ipac Usb Vs, Ps/2
Tiger-Heli:
--- Quote from: AndyWarne on June 14, 2004, 09:00:01 am ---Yes, keyboard PS/2 to USB adaptors are sometimes not good. The Belkin adaptor is particularly bad and cannot be used for gaming at all. That is not relevant to the I-PAC, it's a device problem, not a USB problem. The I-PAC in USB mode is a native USB device and does not use an adaptor.
--- End quote ---
I believe it's a QVS adaptor I'm using, and I stated that I wasn't sure if it was relevant.
patrickl:
FWIW, I was dumb enough not to buy the USB cable and later found out my PC (designated to go into my future cab) does not have a PS/2 port at all! With the new cable it all works fine.
I was just wondering if it would matter if the IPAC is connected to a hub (along wih some other devices like trackball and/or steeringwheel) instead of directly to a USB port on the PC? I saw someone claim using an USB hub might give problems (in the thread on the "expensive clear plexi standalone CP").
RandyT:
--- Quote from: AndyWarne on June 14, 2004, 09:00:01 am ---It does not make any difference if you have high bandwidth devices on the same bus as an I-PAC because the I-PAC uses interrupt transfers (as do all USB keyboard devices) and USB hard disk access, for example, simply has to stop and wait because interrupt transfers always get priority.
--- End quote ---
Allow me to play "devils's advocate" here for a minute, but what happens when 2 (or more) USB devices try to use interrupt transfers at the same time? I believe that's called a conflict.
Any idea where the USB keyboard falls on the OS's list of priorities? Since Microsoft pretty much defines a USB keyboard as being capable of 6 simultaneous keypresses (+ modifiers), one has to wonder what happens in the OS code when that number is surpassed. Likewise, due to a USB keyboards normally small bandwidth requirements, what priority is placed on the keyboard in the event of an interrupt conflict?
--- Quote ---Direct-X has a direct path to USB, the IRQ issue is not especially relevant in Windows.
The proof of the pudding: download the Passmark keyboard test from www.passmark.com. This test has a box called "Lag". (I requested this as a new feature, and they added it). Wire two inputs together on an I-PAC, and check this box when you press the button. You will never see a slower figure in the timer display with USB than with PS/2.
--- End quote ---
If you were only ever going to press 2 keys at the same time, I suppose this would be relevant. But this test really means nothing in the grand scheme of things.
To put your test into perspective, it's very much like seeing what gets to 5 MPH the fastest, a Ferrari or a Lamborghini. :)
If you are going to try to substantiate that claim, a better test would probably be in order, as I'm not sure I would consider that proof.
Just trying to "keep it real." ;)
RandyT
AndyWarne:
--- Quote from: RandyT on June 14, 2004, 01:55:50 pm ---
Any idea where the USB keyboard falls on the OS's list of priorities? Since Microsoft pretty much defines a USB keyboard as being capable of 6 simultaneous keypresses (+ modifiers), one has to wonder what happens in the OS code when that number is surpassed. Likewise, due to a USB keyboards normally small bandwidth requirements, what priority is placed on the keyboard in the event of an interrupt conflict?
--- End quote ---
The chances of a simultaneous interrupt transfer occuring are very slim and even if it did occur, it would not be noticeable. A USB keyboard's total packet length for a transfer is about 40 bytes at 1.5 Mb per second, so the transfer time on the bus is very short. Other interrupt-transfer devices would have similar packet lengths.
The OS does not define a simultaneous keypress limit at all. Microsoft define a standard for boot devices which do have this limit but we are not concerned with this because we are not a boot device. In USB, the device tells the OS what data it will be sending, during enumeration, when it is initialized. The device tells the OS how long its report (ie data packet) length is going to be. We could tell the OS we will be sending reports of 187 keycodes if we wanted to, not that there would be much point. The OS can and does recognise all of these keys pressed at the same time. Also we can tell the OS what priority we want our device to have and many other parameters. The device is king in USB and the OS has to do what it's told.
I have no wish to get into an argument. Just want to get the technical facts about USB correct. There is nothing wrong with the PS/2 interface at all, and in fact for our application it is pretty much as good as USB. I would not like to predict it's demise but if you do a Google search on "Legacy-Free PC" , companies such as Compaq are switching over to USB only. But I would still expect the PS/2 interface to be around for a while.
Andy.
RandyT:
--- Quote from: AndyWarne on June 14, 2004, 05:17:52 pm ---The chances of a simultaneous interrupt transfer occuring are very slim and even if it did occur, it would not be noticeable. A USB keyboard's total packet length for a transfer is about 40 bytes at 1.5 Mb per second, so the transfer time on the bus is very short. Other interrupt-transfer devices would have similar packet lengths.
--- End quote ---
You are quoting theoretical maximum speeds. All USB devices do not communicate at this speed.
from http://www.crucial.com/library/understanding_usb.asp
Understanding USB speeds
Ironically, the speeds associated with USB (480 Mbps, 12 Mbps, and 1.5 Mbps), refer to the theoretical maximum speed of the USB interface on a USB device or USB port and really have nothing to do with the device itself. The actual speed a USB-compliant device achieves is not necessarily the speed of the USB specification reflected in the product descriptions and marketing materials. Real performance of any given product is dependent upon how fast that product can run. The device can only achieve the theoretical speeds if it can keep up with the USB data transfer rate.
--- Quote ---The OS does not define a simultaneous keypress limit at all. Microsoft define a standard for boot devices which do have this limit but we are not concerned with this because we are not a boot device. In USB, the device tells the OS what data it will be sending, during enumeration, when it is initialized. The device tells the OS how long its report (ie data packet) length is going to be. We could tell the OS we will be sending reports of 187 keycodes if we wanted to, not that there would be much point. The OS can and does recognise all of these keys pressed at the same time. Also we can tell the OS what priority we want our device to have and many other parameters. The device is king in USB and the OS has to do what it's told.
I have no wish to get into an argument. Just want to get the technical facts about USB correct.
--- End quote ---
Ok, here's another fact :)
http://www.microsoft.com/whdc/device/input/DxHID.mspx
"Following these recommendations will ensure that the device can be used both by standard Windows