标签: ce_overrun

  CE_OVERRUN Errors with Serial Communications   ******* The communications driver (COMM.DRV) provided with version 3.0 of the Microsoft Windows graphical environment returns CE_OVERRUN errors under "stress" conditions. The text below discusses this error and the conditions that can cause it to occur.   ******* When an application uses the Windows communications functions, it may encounter a CE_OVERRUN error. The frequency of this error depends on the machine configuration; however, the baud rate is normally the most critical factor. Generally, the higher the baud rate, the greater the probability a CE_OVERRUN error. The CE_OVERRUN error indicates an "overrun" of the receive buffer in the universal asynchronous receiver transmitter (UART). The COMM driver obtains this error by reading the line status register (LSR) of the UART -- of which bit 1 is set when an overrun error occurs. When the COMM driver cannot service a Received Data Available interrupt before it receives the next transmitted character, the UART signals an error because at least one character has been lost. One cause that prevents the COMM driver from servicing an interrupt quickly enough is that interrupts are disabled for an extended period of time -- this condition is commonly referred to as "interrupt latency." Some of the biggest contributors to interrupt latency are terminate- and-stay-resident programs (TSRs) such as network drivers, pop-up utilities, and drive cache programs. TSRs are not known to cooperate well with other interrupt-intensive applications, such as the COMM driver. Windows processes communications in this fashion for performance reasons. However, it does leave Windows vulnerable to ill-behaved applications. The COMM driver is very sensitive to ill-behaved applications because, at 9600 baud, characters can arrive at a frequency of approximately 1000 Hz (1 character every millisecond); at 19.2K baud, that frequency doubles. This is near the limit for an interrupt service routine (ISR) running under Windows. There is an additional problem that may cause CE_OVERRUN errors and data loss when running in standard mode on an 80286 computer. Windows must regularly switch the processor from protected mode into real mode to pass data to MS-DOS, MS-DOS drivers, and TSRs. This mode switch occurs a minimum of 18.2 times per second (to update the time-of-day clock). Because the 80286 does not provide a built-in method to switch the processor from protected mode into real mode, the system must reset the processor. This "trick" requires up to 1 millisecond to complete. In addition, during the transition, interrupts are disabled. Therefore, if a COMM interrupt arrives during one of these transitions, it may be lost, which is more of a problem on some machines than on others. The speed of the transition varies depending on the speed of the processor, the speed of installed memory, and other factors. If Windows is running in standard mode on an 80386 computer, losing interrupts should not be a problem because the 80386 is designed to make the protected mode to real mode transition easier and faster. There are even more factors that can affect interrupt latency in the enhanced mode of Windows. CE_OVERRUN errors can occur more often if more than one virtual machine (VM) is running (that is, standard MS- DOS applications are running under Windows). The source of the problem is the enhanced mode Windows virtual machine architecture. There is a certain amount of overhead associated with virtualizing interrupts and device ports. However, the largest problem in this area is interrupt latency caused by transitions between VMs. Enhanced mode Windows performs preemptive multitasking between VMs. Several times each second, Windows performs a "task switch" from one VM to another. If COMMAND.COM or an MS-DOS application is running under Windows, two VMs are present in the system, one for the MS-DOS application and one for Windows itself and its applications. If a COMM port interrupt occurs while the MS-DOS VM is active, the interrupt cannot be processed because the COMM driver cannot be called until the Windows VM becomes active again. Normally, this will be handled quickly enough, but there are times when the switch does not occur fast enough. Windows 3.0 has a virtual device driver (VxD) to buffer characters until the correct VM is scheduled (the VxD is called COMBUFF.386 and is automatically installed with Windows when a machine is capable of running in enhanced mode). COMBUFF.386 helps to correct this problem considerably; however, it does not eliminate the problem. The following three items are factors that affect interrupt latency and task switches in enhanced mode: MS-DOS spends most of its time in a state that prevents Windows from performing a task switch. Almost every MS-DOS call places MS- DOS into this state. Therefore, task switches cannot occur during file I/O, directory manipulation, screen I/O, getting or setting the system time, and so on. Even running COMMAND.COM in a Windows window incurs MS-DOS calls to blink the cursor. Large amounts of file I/O in an MS-DOS application may cause an application to spend a great deal of time inside MS-DOS. Floppy disk file I/O has the greatest impact. If too much time is spent in MS-DOS, a task switch will not occur soon enough for the COMM interrupt to be processed correctly. Interrupts are not processed when interrupts are disabled. There are various times in Windows and in MS-DOS when interrupts are disabled. Also, Windows provide expanded memory (EMS) emulation for banking Windows applications into and out of conventional memory. Interrupts are disabled during the EMS task switch. These times are generally very short, but when they occur in conjunction with task switch latency, they can combine to cause the problem. Higher-priority interrupts are processed before lower-priority interrupts. This often is not a problem; however, difficulties have been seen more often when the system uses a serial mouse. The mouse has a higher interrupt priority than the COMM port. If the mouse is using one of the COMM ports, communication with the mouse is relatively slow. Therefore, if the mouse is very active, mouse processing takes a high priority and a relatively long time to complete which may cause the system to miss a COMM interrupt. In all of these cases, a faster machine performs better because the time spent in MS-DOS, or with interrupts disabled, is less, and therefore more time is available to process the COMM interrupts. Running Windows in standard mode on an 80386 machine eliminates the virtualizing layer of Windows and yet retains the improved mode switch of the 80386 processor. Eliminating unnecessary TSRs and MS-DOS drivers may help; decreasing the number of applications and VMs running simultaneously can only help matters. There is no easy, general method to work around this problem. In general, the COMM.DRV performs better at lower baud rates (300 to 2400 baud). As in all serial communications, the only way to guarantee that data is not lost is to use a packet/protocol transmission scheme. Using this type of protocol, it is possible to detect errors in packets and, more importantly, to request retransmission of an incorrectly received packet. Another thing to keep in mind while when developing a communications application is to test with dedicated hardware. For example, if two computers are running Windows in enhanced mode, and data is sent back and forth at 19.2K baud, the system is NOT under stress. Both machines are affected by the interrupt latency inherent in enhanced mode Windows. Therefore, the effective throughput is probably not 19.2K baud. Even though each character is transmitted at 19.2K baud, no adjustment is made for the delay between characters. Instead, dedicate the "remote" machine to an MS-DOS terminal program that can maintain an effective throughput of 19.2K baud. It is quite likely that it will be necessary to decrease the baud rate to 9600 or even to 2400 for the Windows-based application to receive all the data correctly. Another option is to modify the COMM.DRV to support a buffered UART. The source for the COMM.DRV is provided with the Windows Device Development Kit (DDK). The INS16550A UART is pin-for-pin compatible with the 8250 and 16450.