Originally Published: Wednesday, 15 September 1999 Author: Maurice Entwistle
Published to: featured_articles/Featured Articles Page: 1/1 - [Printable]

Winmodems Part 5 - Why the Future Belongs to Linmodems

When I wrote my first piece on Winmodems - Friend or Foe, I was just complaining about my own inability to use my cheap PC to cruise the net. Why? Because I had a Winmodem (softmodem) and there are no GNU/Linux drivers for it. To this date, although a number of modem manufacturers are working on them, there are no drivers for softmodems under Linux....

   Page 1 of 1  

Winmodems Part 4 - Linmodems: A Bad Idea
Winmodems Part 6 - Cruising the Net with GNU/Linux

When I wrote my first piece on Winmodems - Friend or Foe, I was just complaining about my own inability to use my cheap PC to cruise the net. Why? Because I had a Winmodem (softmodem) and there are no GNU/Linux drivers for it. To this date, although a number of modem manufacturers are working on them, there are no drivers for softmodems under Linux.

With the way GNU/Linux is moving into enterprise, and with millions converting to Linux on their desktops, it's only reasonable to expect that good marketing on the part of modem manufacturers demands drivers for the millions of softmodems that will be produced and put into the commodity level, cheap PC's for the average user.

I also hope that the modem manufacturers don't delay creating Linux drivers in the hopes that they will sell more of the older style modems to people switching to GNU/Linux. This only creates bad press. With major computer makers now offering GNU/Linux installed at the factory, I would be curious what kind of pressure they are putting on the modem makers to release Linux drivers. I hope they are.

Although I enjoy most writing about the GNU/Linux community, and how wonderful the sharing is, and how it has proven to be a good software development model, there is no comparison between the amount of email those pieces generate and the volume that comes in about modems. Modems and drivers for Linmodems wins, hands down.

Therefore, I offer you a number of email responses to Winmodems Part 4 - Linmodems: A Bad Idea. I have taken the liberty to edit the emails, slightly. I have corrected spelling and for brevity, left out a few lines not directly related to softmodems, their pros and cons.



Although I have some experience with UNIX, I am not a Linux expert, but I have the following remarks and questions regarding Linux and the soft-modems:

Is Linux supposed to be only targeted only to "servers"? If it is the case, just discard this mail, I am an ignorant. If Linux is supposed to be used on desktop/laptop machines, then the development of soft modem drivers might be a useful and good thing for some people. One could ask if the effort is worth the number of users, and I can not answer this good question.

Soft modems are not good or bad. They have been designed for a special purpose, and they do their job: They are intended to be cheap, take little space and to run on desktop machines (and not on servers) where CPU cycle are not critical because they are not shared among users.

The whole discussion concerning the CPU usage is not an issue: The CPU usage is left to the responsibility of the "system administrator" of the machine: If you are traveling with your laptop, you are willing to use your CPU (or even dedicate all your CPU cycles) to download your emails. If you are a system administrator installing the corporate modem access point and you choose to use a soft modem on a machine being used as a server (any kind of server, login, db, web, disk, etc.) then of course you do not know your job.

Linux can be -and is- used for real-time applications (typically data acquisition/computation/ system control). When it is the case, the machine is "dedicated" to this task and other task get "less priority". One can not expect the same performances from those "secondary tasks."

Would you really need to kill all the other process ?

I do not believe so, since the usage of a win modem does not seem to bother other application under Windows (e.g.: playing CD, editing file and moving windows around while downloading a big file). Of course this depends on the hardware available to the soft modem (I know that sounds weird... ). Very cheap machines without a DSP for example might be overloaded, but the owner does not expect more and is very happy to be able to use his modem. More serious tests are probably necessary to answer this question.

Sincerely, Jean Tedesco


Hi Maurice -

Just wanted to throw my 2 cents in.

1) Linmodems are a recognized compromise. Price in exchange for CPU cycles. Maybe Uncle Jim doesn't have the cycles to spare, but a lot of people do. Do you really need a 400 MHz PIII to run office applications and browse the web? Heck no. Maybe Uncle Jim runs neural networks in the background, but fact is the average user (Linmodem's target audience) doesn't. If you can't spare the CPU cycles don't by a Linmodem. If you can, then why not save a few bucks?

2) Some administrators seem to have a real aversion to real time processing tasks. Well:

(a) I don't know anything about Linmodems, but I build satellite and broadband modems for a living, so I'm not completely ignorant here. There are facets of modems that don't really have to work in real time. Forward Error Correction and Source Compression come to mind immediately, and there are probably others.

(b) Linux had better learn how to handle real time processing properly as we move into the age of realtime multimedia. It's the future five years down the road.

There are my pennies. I wouldn't buy a Linmodem myself, but I think they make a lot of sense in the under $200 PC market where saving $30 makes a difference.

Regards - Jonathan Cromwell


Hey Maurice,

While I agree with you in theory....there is one thing you forgot, even in a multi-task environment there are usually PLENTY of spare CPU cycles. I work for an ISP with over 100,000 users. I shell into our mail server and do a 'top' and it's sitting at right around 95% free CPU....I'm sure if you do the same on your linux box that you will find it sits at or around 98% except when you are compiling a large program, or doing some other process which is CPU intensive.

Now this is not to say that I don't agree with you, cause I do. As I said I work at an ISP, and there are two things which I hate too hear - 1) "LT Winmodem" and 2) "HSP Micromodem"


Winmodems are the spawn of satan, they connect like sh*t, and every time you install a new piece of software without scandisking, defragging, and rebooting you will ruin your connection.

Oh and don't try to open to many netscape windows at once....that will fry it real quick.




I don't like the idea of Winmodems much. It's something that can be done in hardware, and done cheaply enough. And, hey, I've got better uses for making my CPU do some sort of signal processing --- like piping MP3's to my stereo.

But rationalizing about timing loops sounds way too simplistic. Yes, CPU cycles will be used, and CPU cycles that could be used for other things. But they will be doing work, not sitting in timing loops. I don't think anyone would use a timing loop for this. Rather, they would use the kernels built-in timing and timer setting facilities to set up a sampling rate. As I suggested above, we already do time dependent signal things, such as decoding MP3's, with our systems. Winmodems would probably work just fine, and since the sample rate is likely quite low (56KB is an eternity to a modern CPU), it would do it with little appreciable load.

And if I am wrong and the software modem takes more CPU than I think it would, my guess is other processes would be more likely to interfere with the Winmodem than the other way around. If it didn't run at just the right priority, hammering the CPU with a big Gimp render, or, better, hitting the disks hard (generating competing, high interrupt, IO) would be more likely to make the Winmodem driver lose.

Anyway, I'll be interested in hearing other's reactions. I'm sure you'll get lots of replies to this article.

Carson Harding



Ah yes, another person presuming that Windows 95/98 doesn't multi task. Multi tasking is of course running more than one process at the one time, something that all modern operating systems (aside from the Macintosh) do. However, Windows 9x does fall back to cooperative multitasking as opposed to preemptive multitasking when it runs 16 bit applications. With cooperative multitasking, the process has to surrender it's CPU time before another task can execute. Preemptive multitasking forces a task off the CPU.

This is something that almost everyone that has ever done any form of computing science knows, and no doubt you will receive hundreds of needless emails about it.

In Linux you still have plenty of 'spare' CPU cycles, even if you are running 50 processes, simply by virtue of the fact that most of these processes are in pending state. Most daemon processes are doing exactly what the author is accusing Windows of doing: spinning their wheels, waiting for an interrupt.

I understand the author's motivations: WinModems tie the hardware to the software more strongly than they already are.

Asher Glynn



I very much agree with your general feelings about Winmodems, but they are effectively now part of the commodity hardware infrastructure and if we want Linux to run on commodity hardware, it needs to support Winmodems.

The problem is greatest on Laptops where there are now winmodems built in and you would have to waste a PCMCIA slot or carry around an external modem if you wanted to ignore the winmodem built into the Laptop.

I agree with Uncle Jim that Winmodems are a bad idea but that is from a "green field" point of view (i.e. if we were designing Linux hardware from scratch). I disagree with him in that I do believe its worthwhile for there to be Linux support for Winmodems.

I also disagree that it would be such a burden on the system and that winmodem software necessarily needs to use timing loops. I have not looked at the code or the specs for winmodems, but I have done real-time hardware oriented programming with Unix. I would be very surprised if winmodems don't support some form of queuing and hardware interrupts. This would allow the Linux cpu to merrily do all its other tasks/processes and be called when the winmodem is ready to have some processing done on a batch of bits. This wouldn't be much different than managing a sound card and doing some audio signal processing as some of the various music software does today on Linux. Today's processors are so powerful that doing some DSP at the really low speeds of a modem would be trivial.

The main problem I suspect is the fact that the few manufacturers of winmodem chipsets (Lucent, Rockwell, 3Com[?]) are stingy with the technical specs of their chipsets. That is where the pressure needs to be put on. Even if they want to come out with their own binary drivers, they should still be pressured to make the specs available. If worse comes to worse, it should be taken to court on an anti-trust basis as they have obviously given the code or the specs to Microsoft....

Robert J. Berger


Maurice L. Entwistle, maurice@linux.com.

   Page 1 of 1