I need to Increase keyboard buffer size to allow key strokes at 6000 WPM
 

I am using Debian 7 KVM in a cloud and I find the keyboard buffer in a terminal window is about 35 characters in length thus when I run my keyboard emulator, I have to pause after 35 keys in order not to overflow the buffer.

I want to be able to login and dump the instructions to the KVM server then go to the next one. e.g If I wanted a mass roll out of Yacy search engines or other applications.

I know no Human can type that fast. But my Program can on the PS2 interface.
The USB keyboard port maxes out a 700 WPM
over 5000 Word Per Minute

Hi there,

I don't know what you mean by WPM. Talking about typing and typing speed, I would expect something like "keystrokes per second", or maybe per minute (though I think a minute is an awkward unit). Your WPM sounds more like words per minute, which would be a pretty meaningless thing unless you specify an average word length.

Good news: I'm sure this keyboard buffer can be increased, after all, it's all just software.

Bad news: I've got no idea which knob you'd have to turn. You probably need to tweak the keyboard driver, maybe even recompile your own. Then you'd have to deploy this modified keyboard driver to all your VMs.

EDIT: And what for?? Can't you just ssh into each VM?

And can the PS/2 port read it that fast? AFAIK the hardware is limited to 30 keystrokes per second, which is 1800 per minute. But wait, a keystroke usually consists of at least two codes being transferred from the keyboard - a make code and a break code (key was pressed, key was released). Shift, Ctrl or Alt keys count as keystrokes of their own. So the actual limit is rather 900 keystrokes per second. Only in rapid fire, i.e. auto-repeat when you keep a key pressed, the keyboard doesn't send break codes, but instead a continuous stream of make codes. That's the only way to get 30 per second.
USB might go faster. Technically, at least.

5875 WPM

This link is broken. Did you mean it like this?

[X] Doc CPU

I would suggest switching to a serial console. Much faster.

The PS/2 input device wasn't designed to go that fast. It expects a person to be on the interface.

Use the PS/2 interface only for BIOS interaction, for kernel/Linux interaction, use the serial console. It should operate up to about 115K baud, and has appropriate signals to control overflow.

I don't think the PS2 interface has such.

If you have so much automated interaction, it will NOT be reading the responses. Most sites with multiple systems will use a command distributions service (cfengine for an old instance). ssh will even work better than using a PS/2 interface.

Yes I did mean that.

A serial console interesting but I am using a cloud version so have to go thru windows first.
The PS/2 port can be clocked at around 18 kHz, Its the length of the buffer I need to increase.


The PS/2 has Parity checking and protocol if errors are received.


I will have to look up cfengine.
I am just looking to setup cheap cloud servers for people.

"cloud" doesn't make any sense when talking about a console like a ps/2 interface - that is hardware.
So has the serial interface when it is turned on - as well as cts/rts in hardware to prevent hardware buffer overflow. Also there are USB serial intefaces with a much higher connection speed.
The major problem is picking cheap motherboards not designed for server use. Those that do tend to support both a PS/2 style connection, or USB console connections (preferred). USB is faster and uses DMA, where the PS/2 is limited to either pio or low speed interrupt.

And using a network is faster and simpler yet.

Use of the low level PS/2 console (and keyboard operation in any case) is only usable for initial installations - configuring the BIOS for a netboot. Once set, the PS2 interface is unneeded as the system may now be remotely booted (pxe) and managed over the net. I have seen PXE used to setup an entire virtual machine from scratch to operational in 15 minutes. The longest operation was defining the system to the DHCP server (getting the MAC address from the VM definition), defining the system to the PXE server, and issuing the pxe boot packet (or manually telling the VM to netboot). Once the system is installed (even partitioning was done via the PXE install boot) ssh management was simple.

And in case the system had a problem, it could be reinstalled with a single command (and then wait 10-15 minutes during the rebuild).