Slashdot Mirror


LinModems?

Polo was the first of several to send us an article over at LinuxWorld about PC-Tel announcing LinModems, eg, software modems that can run under Linux as well. Some interesting comments in there about hardware modems being a "Luxury" item. Kinda amusing.

3 of 219 comments (clear)

  1. What planet are these people from? by DeadFish · · Score: 5

    Although a hardware modem can cost up to five times more than a software modem,t hey are relatively cheap, with a current price tag at $100... ... 'I think that [in the future], a hardware modem will be a high-end luxury item'"

    Okay. So even though hardware modems are *already* fairly inexpensive and will continue to go down in price, they are going to be high-end luxury items? $100 is not a high-end luxury price. The only way anyone could consider a modem high end is if everything else available was complete garbage. Of course, this *is* the prediction of a winmodem software manager

    Personally, I fail to see how, with DSL, cable, and ISDN becoming cheaper and more available, any modem could be considered "high end". If you want high end connectivity, why modulate and demodulate a bunch of analog signal?

    Traditionally, software modems have a bad reputation in the linux community. In fact, they've earned the nickname "WinModems" because many are optimized to work with the Microsoft Windows operating system, and refuse to cooperate with any other OS.

    Funny, I always thought they "earned the nickname WinModems" because they say "WINMODEM" on the frigging box. It's the fricking model name, not a nickname.

    They do not just have a bad reputation in the linux community, they have a bad reputation among just about anyone with any idea how modems work. And it's not because they aren't very cross-format, it's because they are lousy modems. I work at an ISP, and I can say with some certainty that the loathing and contempt our tech support has for WinModems is *not* because they only work on windows, but because they barely work at all

    Phew. Felt good to get that out. So anyway. What planet did these people say they were from?

    --
    Another damned comic
    +++ NO CARRIER
  2. Re:Quality of Service by Mr+Z · · Score: 5

    You mentioned the following:

    Rather, in order to correctly interprete the wave signals from the modem in software required that the driver execute at specific times.

    For a perfect software modem, yes, this is true. But for a simple software modem, there are many things you can do to be "good enough", including the following:

    • Buffer up alot of samples to increase your tolerance for latency. The buffering could occur via DMA to system memory, I imagine.
    • Run as a real-time task or interrupt driven device driver to place your priority over the rest of the tasks on the system.
    • Treat dropped samples as line noise and just request a retransmit if you can't error-correct the glitch.
    • If you miss getting samples out to the board in time, no worries -- replay your previous samples and pray the link was idle so it just looks like the idle-time carrier. If it wasn't, the remote modem will behave as if it were line noise and all will still be well.

    After all, Win9x has the same problems as Linux does in this regards (eg. no guaranteed hard-real-time scheduling), yet software modems seem to function passibly in such an environment. If anything, Linux would probably do better than Win9x at this same task. In any case, missing a real-time deadline with a soft-modem would look like lag to the end user and little else. Annoying, but not fatal.

    Now, I'm not running out and signing up to buy a soft modem (particularly since I'm about to get DSL service, obviating the need for a POTS modem almost entirely), but there are some interesting ideas that could make LinModems popular, depending on how open PC-Tel is.

    • Software modem lights that actually work. (The ones I've seen in the past were worthless for actually diagnosing modem troubles. Eye candy at best.)
    • Real-time modem connection quality statistics, such as number of retrains, current symbol rate, etc... perhaps via an entry in /proc. The more detail, the better.
    • General on-the-fly control of modem parameters, such as explicitly requesting fallback/fallforward. For instance, lower symbol rates tend to work alot better for interactive sessions since latency is lower, but higher symbol rates tend to be better for downloading. You could actually request the modem to fall forward or fall backwards by signalling the driver directly. You can't really do that with an external modem.
    --Joe

    --
  3. Re:Maybe They'll work better... by rde · · Score: 4

    You won't see improvements, you didn't get first post, and Suse 6.2 is just about out (if it isn't already).
    Happy birthday.