|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Wednesday, 8 September 1999||Author: Maurice Entwistle|
|Published to: featured_articles/Featured Articles||Page: 1/1 - [Std View]|
Winmodems Part 4 - Linmodems: A Bad Idea
The following is an email I received concerning my piece on "Winmodems." Since I may have been way out on a limb, and pontificating without enough facts, I offer you Uncle Jim's analysis of why softmodems for GNU/Linux are a bad idea. I have Jim's permission to submit his email to the public. I will forward any response to him....
The following is an email I received concerning my piece on "Winmodems." Since I may have been way out on a limb, and pontificating without enough facts, I offer you Uncle Jim's analysis of why softmodems for GNU/Linux are a bad idea. I have Jim's permission to submit his email to the public. I will forward any response to him.
by Uncle Jim
I met you tonight at the kclug meeting and helped Ed make your modem work under Linux (it DOES still work, doesn't it). When you told me about your success with linux.com I looked up and read your articles.
Although I feel privileged to know a successful author, I must say that I believe you are completely wrong on your view of winmodems.
A winmodem is an inherently bad idea, at least in a Linux system. It is interesting to realize that you can replace most of the hardware of a modem with software but you need to consider the environment.
In the days of the single user machine that had a Teletype as the system console (110 baud) we discovered that you could do a lot of work between keystrokes coming in or characters going out. So we looked for something to do with those wasted CPU cycles. Several innovative uses were found.
In 1975 Byte magazine held a conference in Kansas City to discuss the format of bits on audiocassette tape. They came up with what they called the "Kansas City Standard" that PCs could use to save data to tape (the 8" floppys were too expensive for most people). The hardware was minimal and all you had to do was devote your whole machine to writing bits to the tape. You could do the timing in software because you were the only process.
This was fun and it even worked. However, as it usually happens, when the programmers come up with something really good the hardware guys steal the glory and implement it in hardware. The software guys are again left with unused CPU cycles. Eventually they discovered the idea of multi-tasking and there was no longer the concept of "unused CPU cycles". Linux is a multi-tasking OS. At a command line type "ps aux" and you will see all the independent programs (processes) running on your computer. Probably about fifty.
The Microsoft world is NOT multi-tasking (except for NT). This means that they still have lots of unused CPU cycles. So as a modem manufacturer, if you decide to target the MS-Windows users you can save money on hardware by implementing most of the modem in software (using those CPU cycles that were not being used, anyway). This is a great product for the MS-Win market. However, if you had another use for those "apparently unused CPU cycles" (like multi-tasking) the winmodem is not such a good idea. Then if you look at the code that is necessary to make a winmodem work I suspect you will find "timing loops". A timing loop is a piece of code that just wastes time in a controlled fashion. It provides accurate timing but at the cost of wasted CPU cycles.
If I wanted to find out how a winmodem worked I could use in-circuit-emulators (like Hp 64000) and logic analysers (like Hp 1620) and there would be no more secrets. But in the Linux world creating a "linmodem" would be both a neat software trick and a shot in my foot with a large caliber gun. I would have to kill off 49 other processes just to make my modem work. My NIC card, which runs at 500-1000 times faster than my modem would have to stop while I do the timing loops for my modem. Yes, I could invent the "linmodem" but the question is WHY.
In the world of MS-Windows, where the world is but a single process, a device like a winmodem is a good idea. In the Linux world id is a killer.
Somebody may take the time to invent the "linmodem" and I will acknowledge a great programming accomplishment. But there is no way I would ever USE a winmodem, I have too much else to do with my CPU cycles.
I see the "linmodem" as an example that a really good programmer can find out how to work the hardware AND a good way to kill a good Linux system.
An example of what I had in mind here is some of the very early games on PC. The software needed to move a spaceship across a bit mapped display when all you can do is turn pixels on and off with a slow CPU is quite an accomplishment. Some of those early games were not much as far as a game goes but were wonderful pieces of software. Then hardware people like Atari made chips that would move the spaceship across the screen and all the software had to do was setup a few registers to set the speed and direction. Now you could have lots of spaceships and with colour and smooth movement. The software guy no longer gets to enjoy the glory of making a spaceship fly across the screen, now he has to start making the game fun to play.
I enjoyed it, too. I think the open source nature of GNU and the spark of Linux are what is bringing back the mentoring. Ed's comment in the elevator about why the Unix group failed and why the Linux group hasn't sums it up pretty well.
Maurice L. Entwistle, firstname.lastname@example.org.