TIP: Click on subject to list as thread! ANSI
echo: hs_modems
to: JOHN ALDRICH
from: RICK COLLINS
date: 1997-07-11 20:40:00
subject: Modem Selection? Answers?

On Jul 10 08:30, 1997, John Aldrich of 1:362/669 wrote:
RC>> Absolutely _wrong_.  A 286 can handle data much much faster than a 33.6
RC>> modem can hope to provide it.  Even a 4 Mhz 8086 has no problem with the
RC>> data rate from a 33.6.  Problems with those speeds on older hardware is
RC>> usually correctable by replacing the non-buffered UART (either an 8250 
r
RC>> 16450) with a buffered UART like the 16550.
JA> That's interesting, because my roomie, who's a TECH for a local computer 
JA> store, told me that our old Commodore Colt (an old 8086 CPU machine) 
would 
JA> not be capable of handling anything more than a 14.4 modem....even with a 
JA> 16550 UARTed serial port.
That's quite possible - it depends on the architecture of the machine and how 
well (or how poorly) it supports interrupts.
JA> Please forgive this question, but what are your qualifications to discuss 
JA> whether or not a certain CPU can handle a 14.4? I mean no disrespect, 
JA> simply I don't know you, and I came in late on this discussion. :)
The simplest answer is to tell you that I have done it, and know others who 
have as well.  In fact, I know one guy who has operated at 14,400 with no 
problems with an old XT - and _with_ an 8250 UART.
The question really comes down to whether or not the computer can service the 
interrupt quickly enough, and that is determined not by the processor speed 
(all are far faster than the data rate from the modem) but by the other 
hardware in the system.  A particular problem is disk drives:  When you 
access a drive to write, parts of that operation cannot be safely 
interrupted, therefore interrupts have to be disabled.  Hopefully, they get 
enabled again before two bytes arrive at the comm port, in which case, 
nothing bad happens.  However, if the interrupt is disabled too long, then 
the second byte (without a buffered UART) overwrites the first and you get a 
CRC error.  How long the interrupts are disabled depends more on the disk 
subsystem than on the CPU speed.  A "slow" disk will cause problems, no 
matter how fast the CPU.
That's why people with CRC problems are often told to disable SMARTDRV write 
caches - use of the cache results in fewer disk access, but each access when 
it is made is longer, and therefore the risk of a delayed interrupt rises.
Does that help?
Rick
--- MsgedSQ 3.30
---------------
* Origin: The Warlock's Cave (1:163/215.39)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.