Initially, the serial data from the hardware was received by a Pentium II 450 computer, which ran a succession of versions of Windows while we attempted to get the serial port to accept data without regular and frequent data loss. After consistently failing, we switched to Linux on a variety of machines and have had few problems since. What was difficult about the situation that caused Windows to fail, where even a 80386 running Linux was sufficient ?
The raw data stream consists of 72 byte records that arrive
100 times per second over a 115200 baud serial cable
with hardware handshaking. Each eight bit character
is surrounded by two framing bits, so the link is running
at 
of its theoretical capacity with
of unused time in every 
interval.
Most serial port hardware implementations have a
fifo, so five interrupts are needed to
transfer one data record from the wire into memory
(unless a nonstandard polling architecture is used).
About 
after the interrupt is raised,
if the operating system has still not serviced the
interrupt, the fifo becomes full and data delivery
from the wire is paused by the hardware handshake.
We are now consuming that buffer of unused time,
which is shared among five interrupt events. Thus,
the operating system must achieve an average interrupt
response time of 
, and even one response time
in excess of will always cause data loss.
Our reference test used a simple Visual Basic program that grabbed data from the serial port as fast as possible, inspected it to determine whether any loss had occurred, then immediately discarded it. No user (or GUI message) communication occurred while the test was in progress. Data loss was observed to occur on average once every couple of minutes with the network cable plugged in, reducing to every ten minutes or so with no network and every normal user configurable item optimized. Touching the mouse or keyboard caused data loss events every ten seconds or so.
We modified the data stream so that it was simply delivering timestamps to the host computer with no other information content. The test program was extended to gather statistics. We found that there were gaps due to missing data in excess of ten seconds duration several times per day. Although we experimented with the advanced configuration choices and considered non-standard hardware installation, these were not viable long term solutions due to the cost and complexity impact on the end user.
On occasion, we still need to run the original Visual Basic software that predates the Linux port. This is now reliably achieved by having it connect to a serial port emulation provided by the Dialout/IP client from Tactical Software. Under the emulation is a raw TCP/IP connection that goes to a Linux computer, which actually operates the serial port and has a fifo implemented in software that can hold several minutes of data.
An old 80386 class computer (running Debian 2.1) was found to be comfortably sufficient to provide reliable serial I/O and client network communications. On this machine, we benefitted from the irqtune utility in the hwtools package, which can place the serial port interrupt at the highest priority. When this was done, we could run other software from the 80386 console terminal without impacting serial port operations.