Many of us have most obviously suffered the effects of com port overruns when first setting up a winsock. As a result, we've often assumed that since overruns screwed-up the TCP transactions we were trying to tune, changing the TCP settings would somehow eliminate the overruns.
Unfortunately, that's like trying to cure the failure of your basement sump pump by eliminating roof leaks. Without the leaks, you may not be bothered about the bad sump pump - but it's still down there.
When your web browser asks your winsock for an HTTP transfer of a web page, the winsock asks your com port to ask your modem to ask your Internet service provider's modem for data. When a TCP data segment comes back, it's wrapped in an IP transmission unit, which is wrapped in a PPP frame.
The two modems only see a block of data bytes to be sent between them. Until those bytes get through your com port and are written into the area of RAM your winsock is using for its buffers (the "socket" it's servicing for your web browser), they are invisible to the TCP/IP protocol routines in the winsock.
When your modem receives a frame of analog data symbols from your ISP's modem, it loads the data contained in them, one bit at a time, into your com port's UART. (Or, in the case of an internal modem, its on-board processor emulates that process in firmware - presenting your computer's internal bus with an interface that looks like the back end of a 16550A UART chip.)
When the UART is loaded to its Rx Trigger point (only one byte for an 8250 or 16450, but typically 8 bytes with a FIFO-equipped port, like a 16550A), it raises an Interrupt ReQuest (IRQ) to ask your CPU (386, 486, Pentium, etc.) to come empty the data.
After finishing the routines to service any higher priority IRQs (like from your hard disk controller), the CPU responds at the next clock cycle (unless your too-clever video card driver steals the cycle).
If your CPU doesn't get there within the time your modem has been told it will (by your com port's data rate setting), your modem, asssuming it can be unloaded at the data rate setting, will allow the other modem to send more data bytes. Your modem will then write them into the com port's UART - on top of the old data - "overruning" the rate at which the CPU empties the UART.
The PPP buffers in your RAM get loaded with a PPP frame which is missing the overrun bytes, so the PPP routine's error check on the data bytes in the frame doesn't match the included check-sum.
Your winsock doesn't bother calling its higher protocol routines to unwrap the TCP/IP packet. Its PPP routine screams "PPP frame check error," in the hope that allowing the remote TCP sender to get tired of waiting for an "ACK" from your winsock's TCP routine will induce it to re-send the TCP/IP packet again, to be wrapped in a new PPP frame that will work better the next time.
(If that triumph-of-hope-over-experience yields still more PPP frame check errors, your PPP routine and the one in your ISP's server will eventually conclude that the line is hopelessly noisy, and hang-up the modems.)
Since it notices that the reason the frame check failed was missing bytes (rather than garbled bytes from failed modem error correction), your winsock assumes a problem down in the data link layer (your communications "basement"), and also blurts "com overrun" to you.
The CPU/com-port duo can't do their job (of matching your com port data rate setting) in a timely fashion. This is independent of the fact that the job came about because of a PPP transaction, which came about because of a TCP/IP transaction.
As long as your CPU gets distracted for too long by too many other responsibilities to keep up with your com port rate setting, you will have overruns. You can only eliminate them by reducing those distractions, or by reducing the com port rate.
While there are sections in this FAQ dealing with both topics, tuning TCP/IP settings (like MSS, RWIN and MTU) will not cure COM OVERRUNS. Start with your data link layer, and work your way up through each layer of the protocols you use. No layer will work well if any of the layers beneath it are unsound.
This FAQ is available as a Windows Help® file for off-line viewing
Copyright© 1995 by Albert P. Belle Isle