Winmodems

Windows-specific modems work only under Windows because they are not real modems. They are essentially just digital signal processing (DSP) chips; all the modem functions are accomplished in software that, in most cases, is available only for Windows. This makes them cheaper than real modems by a few dollars, and therefore drives real modems out of the marketplace, which is not pleasant for users of non-Windows platforms who need modems.

But even if you are using Windows and it supports your Windows-specific modem, you still might have some unpleasant surprises:

• When you install a new software package, the modem stops working. The error might be something like "Failure to load DSP". The new software package destroyed or renamed some unknown Windows Registry entry, DLL, or other file on your disk, which is a critical part of the modem. Real modems are self-contained and are therefore immune to this phenomenon. You'll need to reinstall the "modem" or Windows itself to recover.

• You might not be able use your sound card when you are using your modem, because the modem uses the sound card for analog/digital conversion.

• Modem calls will often fail for mysterious reasons related to your sound card or who knows what else. Often, you will need to reboot, perhaps more than once, to clear the problem.

There has been considerable debate about whether these modems, by demanding realtime service from their host Windows computers, impact performance of Windows and its applications. The answer no doubt depends on many factors: the make and model and configuration of the PC; the exact Windows version; the "modem" chip, the driver and version, and so on.

On a typically equipped PC delivered with Windows 95 and a 56K Windows modem preinstalled (and all the other pieces found on recent-model PCs, including sound card, CDROM, etc), frequent "freezing" of Windows was observed during data transfer over the modem, as well as other disconcerting effects; e.g. keystrokes delivered from the event queue in reverse order, rectangular "holes" in GUI windows, etc.

Morever, its performance as a modem, compared to a real modem, was not good. In a controlled test using a Kermit script (similar to this one) that repeatedly dialed a dedicated (i.e. otherwise idle) terminal-server based 56K modem pool, logged in to a host, uploaded a 100K ZIP file, downloaded the same ZIP file, and logged out, the following results were obtained with the 56K Windows modem:

  Calls:                   1704
  BUSY:                      16
  NO CARRIER:                 2
  Other call failures:       14
  Complete:                1672
  Disconnections:           227 = 13.6%

NO CARRIER indicates the call was answered but the modems failed to negotiate a connection protocol. "Other call failures" include ERROR (the modem failed to read a setup or dialing command correctly) and disconnection immediately after the CONNECT message.

For the calls that were completed and not disconnected, the following throughput was observed (the figures would be lower if disconnected calls were included, since the CPS of a failed transfer is 0):

                         Uploads Downloads
  Mean CPS                 2426     4979
  Minimum CPS              1237     1887
  Maximum CPS              2910     5156
  Standard Deviation        106      370

When we ran the same script with an external 56K modem on the same PC, we obtained the following results:

  Calls:                   2112
  BUSY:                       7
  NO CARRIER:                 0
  Other call failures:        0
  Complete:                2105
  Disconnections:             0 = 0%

                         Uploads Downloads
  Mean CPS                 2700     4765
  Minimum CPS               518     2111
  Maximum CPS              3257     5157
  Standard Deviation        332      779

Conclusions:

• The external modem never failed to make a connection if the number was not busy.

• The external modem never dropped a call, whereas the Winmodem dropped more than 13 percent of all completed calls, most of them during data transfer.

• For calls that did not terminate abnormally, file transfer throughput is somewhat more variable for the external modem, but that's because it did not give up and disconnect the call at the first sign of trouble; for every call that was completed, the file was transferred back and forth successfully, even if the connection was awful.

• As noted, the external modem did not interfere noticeably with Windows and its other applications, whereas the internal Windows modem made the PC very difficult to use during these trials.