NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/sys/ibm/pc/hardware/33608

Text File | 1992-12-20 | 5.8 KB | 131 lines

Path: sparky!uunet!valinor.mythical.com!n5ial!jim
From: [e-mail] (Jim Graham)
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Internal 14.4K Modems
Message-ID: <[e-mail]>
Date: Thu, 17 Dec 92 16:06:47 GMT
References: <[e-mail]>
Distribution: world
Organization: Me? Organized? Hah! :-)
Lines: 119

In article <[e-mail]> [e-mail]
writes:

> Zoom's stuff appears to be as hardy as the big names USR and
> Practical Peripherals but doesn't put much into marketing.

I trust you meant to type USR and Telebit....we knew what you meant,
though.  my USR DS modem is currently feeling rather insulted that you
would compare it with a Zoom modem.  from what I've heard, the Zoom
modem is a real lemon.  I usually don't put a lot of faith into an
isolated comment here or there that a modem sucks, but this is one of
a few that I seem to keep hearing about, so I'm a bit more likely to
believe them....

> PC Magazine wrote up a good review on a large
> number of V32bis modems and I think Zoom was hard to beat for the price.

pc magazine's modem reviews are not exactly something you want to put a
lot (or any, for that matter) of trust into....they tend to be full of
errors, omissions, etc., and I wouldn't trust them as far as I could
throw the computer they wrote them on.  of course, my field is data
communications, and modems are one of the areas I work with a lot....I
would tend to spot these a little faster than most pc magazine readers.

> If you are looking for trouble free high speed communications under
> Windows you'll be lookin' a long time.

no argument there....  windoze + high-speed modems = Bad Thing.

(gee, I sure do sound negative this morning, don't I?  strange....)

if you want multitasking AND high-speed modems, take a look at Desqview.
it's a heck of a lot cleaner than windoze (in every way, IMHO), and you
shouldn't have any problems there.  I'd still upgrade the serial board
to a 16550A (or AF), though...I had to upgrade just to support the port
reliably at 38.4 kb (for V.32bis w/ V.42/V.42bis) WITHOUT multitasking.

> The buffer on the 16550A is only
> 16 bytes or about 4 milliseconds long at high communications speeds.

yes, but you're only looking at one small part of what the 16550 buys
you.  the following is extracted from one of my old posts on this
subject to comp.dcom.modems (I've trimmed it a little):

----------------------------  CUT HERE  ----------------------------
From: [e-mail] (Jim Graham)
Newsgroups: comp.dcom.modems
Subject: 14400 modems and 16550 UARTS (Problem with higher trf
Date: Wed, 18 Nov 92 23:25:27 GMT

[original quote deleted]

taken literally, the above is true....but there is more to it than
just the above (and this bit isn't talked about as much here).  see,
the buffers are only the first part of what the 16550 buys you.  the
second part is a little thing you can do *WITH* those buffers, that
being reducing the number of interrupts generated.  remember that every
time an interrupt is issued, the CPU has to stop what it's doing to
service the interrupt.  this doesn't happen instantly...there is a
certain amount of time wasted when the CPU is changing tasks (context
switching overhead).

the 16550 can help reduce the number of interrupts required (assuming
your software goes along with this) by allowing more than one character
to be handled per interrupt.  basically, you can tell the 16550 not to
issue an interrupt until a certain number of characters are in the Rx
FIFO (1, 4, 8, or 14).  let's assume we set this to 8 characters.  now,
instead of every single incoming character causing an interrupt, the
UART waits around until EITHER their are 8 characters in the Rx FIFO
*OR* a certain amount of time has passed w/o an interrupt being issued
since there was at least one character in the FIFO (in other words, it
doesn't sit there like an idiot and wait forever).

along with this, of course, your software has to know that it might be
taking more than just one character for any interrupt it services.

btw, this information is adapted right out of the National Semiconductor
data sheets (Application Note 491, ``The NS16550A: UART Design and
Application Considerations'').

----------------------------  CUT HERE  ----------------------------

once I've gotten my NS data sheets unpacked, I can post the exact
wording if anyone is interested (I know I've posted it before...maybe I
can find the ascii file somewhere --- no telling which box my NS data
books are in).

> THerefore you will more often than not run into data overrun problems
> at high speeds under Windows. Best to compress the files at the source
> or transfer pre ZIPped files.

that doesn't address the problem, though.  the problem is that you have
a steady stream of incoming data at a rate that the computer can't keep
up with.  transferring pre-compressed data isn't going to change that.
the real problem is that the computer can't handle the interrupts fast
enough.

now, if you're looking at text (or other easily compressed data), then
it can help by slowing things down a bit.  pre-compressed data is going
to level out at around 1650 to 1700 cps (with V.32bis/V.42/V.42bis),
whereas text might go as high as 2600 cps (possibly even higher in some
rather unusual cases).

> Better yet do your
> high speed data transfers under DOS.

no argument there.

gotta run.
   --jim

--
#include <std_disclaimer.h>                                 73 DE N5IAL (/9)
------------------------------------------------------------------------------
INTERNET: [e-mail]  |  [e-mail]
          [e-mail]       (OLD): [e-mail]
AMATEUR RADIO: n5ial@w4zbb        AMTOR SELCAL: NIAL       ICBM: 30.23N 86.32W
------------------------------------------------------------------------------