Hi Peter,

IS>PC>If by an 'ordinary serial port' you mean a 16450 or 8250 UART then
IS>PC>you
IS>PC>should be able to run a 28k8 or 33k6 modem without problems as
IS>PC>long as
IS>PC>you don't run a multitasker (win/Desqview/OS2 etc)

[Aside: using a shorter quoted line length, requotes will look better :]

IS> PH> With a 8250 or 16450 UART he'd be lucky to properly support a
IS>V32 modem,
IS> PH> let alone V34 or V34+ modem!

IS>No, that's not so, Peter; not if you're not running multitasking.  A
IS>10MHz XT with an 8250 UART (or an AT with a 16450) readily handles a
IS>57600bps port at sustained rates, though 115200bps tends to be a bit
IS>too flakey.
[..]
IS>Multitasking (ie interrupt latency) changes the picture completely,
IS>including some disk caching software on an otherwise non-multitasked
IS>PC.

 PH> I beg to differ. Certainly I have found that Laplink using
 PH> ordinary serial
 PH> ports successfully sustains transfer speeds such as you suggest, but my
 PH> experience and that of friends using mainly Telix, (dos version), found
 PH> that a V32bis modem that established a V32bis connection could not
 PH> reliably sustain that connection speed with out 16550 uarts.

Strange.  Did he have hardware flow control enabled, with Telix turning off
CTS during disk writes (necessary with some machines)?  I've seen enough
poorly configured Telix setups to be a tad skeptical :)

 PH> Any connection at that speed tended to suffer from port over runs,
 PH> dropped characters, lots of retrys and fluctuating download speeds,
 PH> all fixed when we added 16550 uarts.

 PH> I should point out that we were all running our dos communications
 PH> programs from the dos prompt, with out a multitasker/task switcher
 PH> being loaded.

 PH> ?

I suspect he was probably running SmartDrive, or some other disk caching
software, or some other TSR software that introduced interrupt latency?

With a 19200bps port rate (likely rate, amidst block bursts, from a V.32bis
modem) a character (thus interrupt) arrives every 520 microseconds.  As the
8250A/16450 UART buffers one byte (thus can hold two complete bytes before
overrun) you need a maximum interrupt latency of less than about 1
millisecond to keep up with the data stream without losing any characters.

A 'straight' PCXT/10, or any PCAT or better, has no problem with that at
all; however anything that disables interrupts for longer than about a
millisecond is going to then miss the odd interrupt (thus, block!)  Most
DOS disk caching software using lazy writes will violate that limit, quite
regularly, and then having Telix drop CTS on writes won't help, as the
writes are asynchronous.

Anyway, there's no argument, buffered UARTs are much better, and will solve
lots of problems for most people - but "8250A/16450s won't work"
isn't nearly close enough to the truth, without the rider of mentioning
multitasking or some other process of asynchronous interrupts causing
excessive latency.

Heck, I remember Trev Roydhouse having his ol' Desqview system funely tuned
enough to run a 16450 UART full tilt at 14400, on an (I think) 12MHz AT :)

 PH> Have a great day,

Spring is well and truly sprung up here, great days for sure!

Ian

--- MaltEd 1.0.b5