8250 UART vs. 16550 UART
Peter H. Granzeau
On 16 Feb 1997 21:40:01 GMT, obi...@engrs.unl.edu (Marc Lombardo)
wrote:
>My questions are:
>
>Will upgrading to a 16550 UART increase my transfer speed
>in dos by a decent amount? (allowing perhaps the 1.7K/s shown in the USR
>manual for compressed files at 14.4k, serial port set at 38400 or 57.6K
>using v.42bis)
In my case, with a 16 MHz 80386SX, it did. I had something similar to
your problems with VT100 emulation dropping characters, as well.
>will upgrading to a 16550 UART allow me to use my tsrs and still achieve
>the same, or just about the same transfer rates?
This one I don't know about, since I didn't have a tsr problem.
>will upgrading to a 16550 uart allow me to achieve fast transfer rates even
>when i'm in windows?
That's what it is supposed to do. When a computer is multitasking, it
is easier for it to lose a character in an unbuffered UART.
>is it possible that my bios (ami 1989) is also causing some problems with my
>com port and making the data garbled (i.e. vt100 instructions not working
>properly, lower transfer rates, etc.)?
I don't know about this one, either. I started out with a 1991 BIOS.
Marc Lombardo
hi,
i'm using a 386sx (20mhz!) with a 1989 AMI bios, a 8250 UART and a US Robotics
14.4K V.32bis with V.42bis Sportster modem. I have my serial port rate set at
19.2K, and connect at 14400/ARQ/V32/LAPM/V42BIS. I am using a dial-in modem
telnet server and after connecting to my unix (AIX) account, I send a break
and do a 'set session passall' at the telnet prompt, as recommended by the
system for successful zmodem transferring. I also set the modem to &K3 to
disable MNP5 compression since I download compressed files almost exclusively.
I can only successfully download files using zmodem without errors when I
unload the majority of my TSRs and even then only get a max transfer speed of
about 1k/sec with compressed files. I get tons of serial port errors (data
overruns) when EMM386 or Norton AntiVirus are loaded. I cannot get zmodem
transfers to work at all in the QuickLink II/FAX program included with my USR
modem.
I cannot get transfer rates above about 500-600 bytes/sec in Procomm for
windows.
I often have problems with the vt100 instructions not working properly as
well, causing my screen to be too garbled to use (especially when TSRs are
loaded, notably again EMM386 & Norton AntiVirus TSR, among others).
My questions are:
Will upgrading to a 16550 UART increase my transfer speed
in dos by a decent amount? (allowing perhaps the 1.7K/s shown in the USR
manual for compressed files at 14.4k, serial port set at 38400 or 57.6K
using v.42bis)
will upgrading to a 16550 UART allow me to use my tsrs and still achieve
the same, or just about the same transfer rates?
will upgrading to a 16550 uart allow me to achieve fast transfer rates even
when i'm in windows?
is it possible that my bios (ami 1989) is also causing some problems with my
com port and making the data garbled (i.e. vt100 instructions not working
properly, lower transfer rates, etc.)?
thanks in advance!
--
marc
"no, i can't see tomorrow. when i close my eyes, ... there is no
tomorrow. my kingdom's of no...use. of no...use." 242
Ann and Michel PY
Marc,
Your problem is with the 8250 for sure ( overrun errors)
I recently de-soldered 2 8250 and replaced them with 16c550
(the chips are pin-compatible). Works fine now.
Other things to check : ISA bus speed. on some 386sx boards, it's
4.77 mhz.
Paul Hustava
In article <5e7urh$s...@crcnis3.unl.edu>, obi...@engrs.unl.edu (Marc Lombardo) wrote:
>hi,
>
>i'm using a 386sx (20mhz!) with a 1989 AMI bios, a 8250 UART and a US Robotics
>14.4K V.32bis with V.42bis Sportster modem. I have my serial port rate set at
>19.2K, and connect at 14400/ARQ/V32/LAPM/V42BIS. I am using a dial-in modem
>telnet server and after connecting to my unix (AIX) account, I send a break
>and do a 'set session passall' at the telnet prompt, as recommended by the
>system for successful zmodem transferring. I also set the modem to &K3 to
>disable MNP5 compression since I download compressed files almost exclusively.
>
>will upgrading to a 16550 UART allow me to use my tsrs and still achieve
>the same, or just about the same transfer rates?
It will be much better with a 16550
>will upgrading to a 16550 uart allow me to achieve fast transfer rates even
>when i'm in windows?
Yes, The 8250 can only operate a maximum of 9600 bps. while that 16550
allows up to 115200 bps
>is it possible that my bios (ami 1989) is also causing some problems with my
>com port and making the data garbled (i.e. vt100 instructions not working
>properly, lower transfer rates, etc.)?
That I don't know
--
e-mail not containing "RE:" in the subject
line will be automatically deleted. (well,
maybe)
Paul Hustava
hins...@inlink.com
John Navas
See my FAQ.
--
Best regards,
John mailto:JNa...@NavasGrp.Dublin.CA.US http://www.aimnet.com/~jnavas/
28800 Modem FAQ: http://www.aimnet.com/~jnavas/modem/faq.html
Mike McCarty
In article <5e8efd$3to...@news.inlink.com>,
Paul Hustava <hins...@inlink.com> wrote:
)In article <5e7urh$s...@crcnis3.unl.edu>, obi...@engrs.unl.edu (Marc Lombardo) wrote:
)>hi,
)>
)>i'm using a 386sx (20mhz!) with a 1989 AMI bios, a 8250 UART and a US Robotics
)>14.4K V.32bis with V.42bis Sportster modem. I have my serial port rate set at
)>19.2K, and connect at 14400/ARQ/V32/LAPM/V42BIS. I am using a dial-in modem
)>telnet server and after connecting to my unix (AIX) account, I send a break
)>and do a 'set session passall' at the telnet prompt, as recommended by the
)>system for successful zmodem transferring. I also set the modem to &K3 to
)>disable MNP5 compression since I download compressed files almost exclusively.
)>
)<snippage>
)
)>will upgrading to a 16550 UART allow me to use my tsrs and still achieve
)>the same, or just about the same transfer rates?
)
)It will be much better with a 16550
You don't know that. Does he have software which can properly utilize
the 16550?
)>will upgrading to a 16550 uart allow me to achieve fast transfer rates even
)>when i'm in windows?
)
)Yes, The 8250 can only operate a maximum of 9600 bps. while that 16550
)allows up to 115200 bps
Hogwash. You obviously are not an expert on the 8250. I have regularly
run the 8250 at 115200 baud, and not missed a character, on XT class
machines (with 8088s in them, not even 8086s). They -were- 10 MHz
machines, however.
)>is it possible that my bios (ami 1989) is also causing some problems with my
)>com port and making the data garbled (i.e. vt100 instructions not working
)>properly, lower transfer rates, etc.)?
)
)That I don't know
You got that right.
Mike
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for DSC. <- They make me say that.
Ray
On 16 Feb 1997 21:40:01 GMT, Marc Lombardo <obi...@engrs.unl.edu> wrote:
>Will upgrading to a 16550 UART increase my transfer speed
>in dos by a decent amount? (allowing perhaps the 1.7K/s shown in the USR
>manual for compressed files at 14.4k, serial port set at 38400 or 57.6K
>using v.42bis)
Upgrading to a 16550 (or even a 16650 with 32byte buffer) should
both improve speed and decrease errors. That said, there may be
something else causing some of your problems. I have a 386SL/25 based
laptop here and it is rock solid under DOS and OS/2 at 19200bps and
fairly reliable at 38400. You should make sure disk write caching is
turned off. You should also check your com software for settings like
"flow control during disk write" and "disk buffer size". Setting the
former to "ON" and the latter to something small (1k or so) should cut
back on errors which may in turn help your speed.
Hope this helps
--
Ray
rv1...@goodnet.com
Elder, Eric
Paul Hustava wrote:
>
> In article <5e7urh$s...@crcnis3.unl.edu>, obi...@engrs.unl.edu (Marc Lombardo) wrote:
> >
> >i'm using a 386sx (20mhz!) with a 1989 AMI bios, a 8250 UART and a US Robotics
The 8250 UART should not be set higher the 19,200 bps, the 16450 for
38,400 bps and the 16550 for 115,200 bps. The most frequent problem with
ports that are overspeeded is comm port overrruns and CRC errors.
--
All opinions are mine and do not reflect policy of my
employer or affiliated organizations.
Sure, we can fix that!
Peter H. Granzeau
>The 8250 UART should not be set higher the 19,200 bps, the 16450 for
>38,400 bps and the 16550 for 115,200 bps. The most frequent problem with
>ports that are overspeeded is comm port overrruns and CRC errors.
There's no reason a 16450 (or 8250) UART can't be run at 115,200 bps
as long as no Windows or other multitasking nonsense is going on.
Per Viggen
When first connecting to the net with my X-link 14.4 modem a couple of
years ago, I used the Trio DataComm prog that came with the modem. I
got downloads at about the same speed as you report - end the VT100
emulation was lousy, scrambling the screen to be almost unreadable. The
dealer advised me to try another comms program!
So I did. Trying the free Kermit program was very exciting, delivering
data in top speed. However somewhat rough and dirty, and the problems
with our special nordic characters forced me to give it up. Then I
tried Telix, and have registered and stuck with it ever since. At first
I did have some download problems (transfer errors), but carefully
reading the manual made me turn "Drop RTS during disk writes" to ON.
This solved that problem, and transfer speed on compressed files are
somewhat around 1600 CPS (bytes per sec.).
My advice: Study the manual for your prog once more. If it cannot drop
RTS, try another comms program (with a good VT100 emulation). You will
certainly get more speed with a 16550 UART, but every decent comms prog
should run well on older equipment (I have used a '286!). Step up on
comms port baud rate until you encounter problems (errors), then walk
one step down.
I am not at all an expert, but has worked for me though...
--
Per Viggen <pvi...@sn.no> << More Power - More Trouble >>
Paul Hustava
In article <5eata2$j...@sun001.spd.dsccc.com>, jmcc...@sun1307.spd.dsccc.com (Mike McCarty) wrote:
>In article <5e8efd$3to...@news.inlink.com>,
>Paul Hustava <hins...@inlink.com> wrote:
>)Yes, The 8250 can only operate a maximum of 9600 bps. while that 16550
>)allows up to 115200 bps
>Hogwash. You obviously are not an expert on the 8250. I have regularly
>run the 8250 at 115200 baud, and not missed a character, on XT class
>machines (with 8088s in them, not even 8086s). They -were- 10 MHz
>machines, however.
No, I am not an expert! I am merely drawing on personal experience,
and every reference I've seen on UART chip comparisons.
I do know that more often than not, an upgrade to a 16550 _will_
improve transfer rates, and decrease errors. Your siuation appears
to me to be an exception to the rule
>)>is it possible that my bios (ami 1989) is also causing some problems with my
>)>com port and making the data garbled (i.e. vt100 instructions not working
>)>properly, lower transfer rates, etc.)?
>)That I don't know
>You got that right.
Relax... It appears that you aren't evan happy when someone admits
lack of knowledge in a certain area.
--
Paul Hustava
hins...@inlink.com
Paul Hustava
>is it possible that my bios (ami 1989) is also causing some problems with my
>com port and making the data garbled (i.e. vt100 instructions not working
>properly, lower transfer rates, etc.)?
>
I did a little research on this last part, and apparently the 8250 (not the
8250A or 8250B) has a bug that was never really fixed, but BIOS's were
written to deal with the bug. The clincher here is that if the BIOS was
replaced without replacing the UART (or vice versa) the bug would rear it's
ugly head, and the data transmission errors would appear.
--
Paul Hustava
hins...@inlink.com
Mike McCarty
In article <330a1da3...@news.exis.net>,
Peter H. Granzeau <p...@exis.net> wrote:
)On Tue, 18 Feb 1997 08:52:12 -0800, "Elder, Eric"
)<eel...@paradyne.com> wrote:
)
)>The 8250 UART should not be set higher the 19,200 bps, the 16450 for
)>38,400 bps and the 16550 for 115,200 bps. The most frequent problem with
)>ports that are overspeeded is comm port overrruns and CRC errors.
)
)There's no reason a 16450 (or 8250) UART can't be run at 115,200 bps
)as long as no Windows or other multitasking nonsense is going on.
There's no reason a 16450 or 8250 can't be run at 115,200 EVEN IF
multitasking is going on.
Well written operating systems don't disable interrupts in a way that
would interfere with serial I/O like this for the lengths of time that
would cause troubles. They only disable the interrupts which might
interfere with whatever is going on at the moment.
We're only talking about one interrupt every 87 microseconds or so. If
Windows didn't disable interrupts for all devices, but only for the
ones which might interfere with context switching (using the
capabilities of the 8259 PICs) then there is no reason that interrupts
should be disabled for that length of time. The disable interrupt
instruction would not even be needed. The interrupt handler would
disable interrupts from that device using a PIC, and re-enable
interrupts in the processor. Shouldn't take more than 5-10
instructions, well under a microsecond on a 100 MHz 486.
Elder, Eric
Mike McCarty wrote:
>
> In article <330a1da3...@news.exis.net>,
> Peter H. Granzeau <p...@exis.net> wrote:
> )On Tue, 18 Feb 1997 08:52:12 -0800, "Elder, Eric"
> )<eel...@paradyne.com> wrote:
> )
> )>The 8250 UART should not be set higher the 19,200 bps, the 16450 for
> )>38,400 bps and the 16550 for 115,200 bps. The most frequent problem with
> )>ports that are overspeeded is comm port overrruns and CRC errors.
> )
> )There's no reason a 16450 (or 8250) UART can't be run at 115,200 bps
> )as long as no Windows or other multitasking nonsense is going on.
>
> There's no reason a 16450 or 8250 can't be run at 115,200 EVEN IF
> multitasking is going on.
>
don't think comments about what a UART can do in DOS are that important.
I have corrected numerous problems that customers have had in a Windows
and Win95 environment by being conscious of port speed limitations and
understanding the relationship between the DTE and DCE speeds.
Mike McCarty
In article <c1.01.2F5Ty0$0...@pentium.goodnet.com>,
Ray <rv1...@goodnet.com> wrote:
)On 16 Feb 1997 21:40:01 GMT, Marc Lombardo <obi...@engrs.unl.edu> wrote:
)>Will upgrading to a 16550 UART increase my transfer speed
)>in dos by a decent amount? (allowing perhaps the 1.7K/s shown in the USR
)>manual for compressed files at 14.4k, serial port set at 38400 or 57.6K
)>using v.42bis)
)
)Upgrading to a 16550 (or even a 16650 with 32byte buffer) should
)both improve speed and decrease errors.
Since the problem is in software, not hardware, you may or may not be
right. It depends on just how bad the software is.
)That said, there may be
)something else causing some of your problems.
Yeah, like software, which -is- the cause of the problems.
[software based fixes which actually may help cut]
Frank Durda IV
Paul Hustava (hins...@inlink.com) wrote:
: I did a little research on this last part, and apparently the 8250 (not the
: 8250A or 8250B) has a bug that was never really fixed, but BIOS's were
: written to deal with the bug. The clincher here is that if the BIOS was
: replaced without replacing the UART (or vice versa) the bug would rear it's
: ugly head, and the data transmission errors would appear.
Please see http://www.freebsd.org/handbook/handbook113.html#194
for everything you ever wanted to know about the 8250/16450/16550 family.
Frank Durda IV <uhc...@nemesis.lonestar.org>|"The Knights who say "LETNi"
or uhclem%nem...@rwsystr.nkn.net | demand... A SEGMENT REGISTER!!!"
|"A what?"
or ...letni!rwsys!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983
Elder, Eric
Frank Durda IV wrote:
>
> Paul Hustava (hins...@inlink.com) wrote:
> : I did a little research on this last part, and apparently the 8250 (not the
> : 8250A or 8250B) has a bug that was never really fixed, but BIOS's were
> : written to deal with the bug. The clincher here is that if the BIOS was
> : replaced without replacing the UART (or vice versa) the bug would rear it's
> : ugly head, and the data transmission errors would appear.
>
> Please see http://www.freebsd.org/handbook/handbook113.html#194
>
> for everything you ever wanted to know about the 8250/16450/16550 family.
>
engineers that also pointed out the port speed limitations of the UART
are due to the Windows environment. One of the references I have on
UARTs indicates the 8250, 8250A, and 8250B all have bugs but the latter
is the most desirable.
B.MacDonald
In article <5eata2$j...@sun001.spd.dsccc.com>, Mike McCarty <jmccarty@sun
1307.spd.dsccc.com> writes>)In article <5e7urh$s...@crcnis3.unl.edu>, obi...@engrs.unl.edu (Marc Lombardo)
>wrote:
>)>will upgrading to a 16550 UART allow me to use my tsrs and still achieve
>)>the same, or just about the same transfer rates?
>)
>)It will be much better with a 16550
>
>You don't know that. Does he have software which can properly utilize
>the 16550?
What sort of software might that be????
>
>)>will upgrading to a 16550 uart allow me to achieve fast transfer rates even
>)>when i'm in windows?
>)
>)Yes, The 8250 can only operate a maximum of 9600 bps. while that 16550
>)allows up to 115200 bps
>
>Hogwash. You obviously are not an expert on the 8250. I have regularly
>run the 8250 at 115200 baud, and not missed a character, on XT class
>machines (with 8088s in them, not even 8086s). They -were- 10 MHz
>machines, however.
Why are you responding to these postings? You haven't the faintest idea
what you are talking about.
Paul is exactly right. The only way you could have operated at 115k
without overun errors is:
* if you were using an internal modem which, by the way, usually have a
16550A chip (or equivalent emulator) built-in.
* or your setup (or a low speed modem - eg, 2400 baud) pegged your
connection (ie, line speed) at a suitably low level... in which case
setting your internal serial speed to 115k was pointless.
* or in your dreams.
If you were running a high speed external modem wide open with a serial
speed set at 115k, you would get overrun errors in short order, as the
processor struggled to sort out the backlog of incoming data. With a
10MHz processor, the effect would be even more pronounced. As the errors
reached critical proportions, your download rate starts to drop off
rapidly until you are receiving little if any incoming data.
The 16550 chip was an attempt to improve serial port throughput, but was
not entirely successful. What is the industry standard now is actually
the 16550A and variations thereof (16550AN, AF, etc). These allow FIFO
(First In First Out) error control. In effect, it organizes the incoming
data in such a manner that it will not swamp your processor's capacity
to deal with it (thus inducing errors). Increasingly over the past 4 or
5 years, most PC's have been shipped with the 16550A chip or equivalent.
PC's built before then, or more recent cheap backroom-built systems, may
still have the older chip. You can either add the higher speed UART,
which is a fairly cheap slot-in card (about 25 US dollars here in the
UK), or you can get a good quality (and recent) internal modem.
Back to your original query, Marc. Your TSRs are not a significant
factor in your problems - the lack of a 16550A UART is.
>
>)>is it possible that my bios (ami 1989) is also causing some problems with my
>)>com port and making the data garbled (i.e. vt100 instructions not working
>)>properly, lower transfer rates, etc.)?
>)
>)That I don't know
>
>You got that right.
>
Amazing. If you're going to be rude, at least make sure you know what
you are talking about first.
--
B.MacDonald, Northwood, Middlesex, UK
E-mail: bu...@nthwd.demon.co.uk
bu...@dircon.co.uk
Dale Shuttleworth
Hi,
B.MacDonald (bu...@nthwd.demon.co.uk) wrote:
: In article <5eata2$j...@sun001.spd.dsccc.com>, Mike McCarty <jmccarty@sun
: 1307.spd.dsccc.com> writes
[...]
: >Hogwash. You obviously are not an expert on the 8250. I have regularly
: >run the 8250 at 115200 baud, and not missed a character, on XT class
: >machines (with 8088s in them, not even 8086s). They -were- 10 MHz
: >machines, however.
:
: Why are you responding to these postings? You haven't the faintest idea
: what you are talking about.
This is always a brave statement to make on Usenet.
: Paul is exactly right. The only way you could have operated at 115k
: without overun errors is:
: * if you were using an internal modem which, by the way, usually have a
: 16550A chip (or equivalent emulator) built-in.
: * or your setup (or a low speed modem - eg, 2400 baud) pegged your
: connection (ie, line speed) at a suitably low level... in which case
: setting your internal serial speed to 115k was pointless.
: * or in your dreams.
Or you're running well written software.
: If you were running a high speed external modem wide open with a serial
: speed set at 115k, you would get overrun errors in short order, as the
: processor struggled to sort out the backlog of incoming data. With a
: 10MHz processor, the effect would be even more pronounced. As the errors
: reached critical proportions, your download rate starts to drop off
: rapidly until you are receiving little if any incoming data.
Why? On a 10MHz processor, the processor has 868 cycles to deal with
each incoming character. If you can't deal with a single character in
that many cycles your programming skills are pretty poor. You can
also use flow control to throttle the incoming stream if you like (handy
during periods where you may have high interrupt latency (e.g. disk I/O)).
: The 16550 chip was an attempt to improve serial port throughput, but was
: not entirely successful. What is the industry standard now is actually
: the 16550A and variations thereof (16550AN, AF, etc). These allow FIFO
: (First In First Out) error control.
Well, I suppose "not entirely successful" is a novel way of writing
broken. The 16550A is pretty much the industry standard as you say,
although TI has a 16550B, 16550C and a 16750 and someone else
(Startech?) has a 16650. The TI 16550C introduces automatic flow
control (which should guarantee zero overruns no matter what the
interrupt latency is) whilst the 16650 and 16750 have deeper FIFOs.
: In effect, it organizes the incoming
: data in such a manner that it will not swamp your processor's capacity
: to deal with it (thus inducing errors). Increasingly over the past 4 or
: 5 years, most PC's have been shipped with the 16550A chip or equivalent.
: PC's built before then, or more recent cheap backroom-built systems, may
: still have the older chip. You can either add the higher speed UART,
: which is a fairly cheap slot-in card (about 25 US dollars here in the
: UK), or you can get a good quality (and recent) internal modem.
:
: Back to your original query, Marc. Your TSRs are not a significant
: factor in your problems - the lack of a 16550A UART is.
TSRs may be a significant problem. If the TSR is some form of device
driver which disables interrupts then it may well cause overrun
errors. If you have a TSR which disables interrupts for 2ms, even a
16550A is going to drop data at 115200bps.
: Amazing. If you're going to be rude, at least make sure you know what
: you are talking about first.
Hmmm.....
Dale.
--
**************************************************************************
* Dale Shuttleworth *
* Email: da...@giskard.demon.co.uk *
**************************************************************************
Chris Quirke
jmcc...@sun1307.spd.dsccc.com (Mike McCarty) wrote:
>In article <330a1da3...@news.exis.net>,
>Peter H. Granzeau <p...@exis.net> wrote:
>)On Tue, 18 Feb 1997 08:52:12 -0800, "Elder, Eric"
>)<eel...@paradyne.com> wrote:
>)>The 8250 UART should not be set higher the 19,200 bps, the 16450 for
>)>38,400 bps and the 16550 for 115,200 bps. The most frequent problem with
>)>ports that are overspeeded is comm port overrruns and CRC errors.
The newer UARTs (16550 etc.) have a 16-byte or larger buffer for data
to be held while awaiting interrupt service.
If service is prompt, you can set it to generate an interrupt after
(say) 12 bytes are recieved, so that you service the interrupt every
12th byte, not every single byte - less processing overhead.
If service is not prompt (IDE block mode enabled, Windows etc.) then
set it to generate an interrupt after (say) 4 bytes are received, then
there's still space for another 12 bytes to be buffered while waiting
for the cavalry to arrive; less risk ov overrun errors.
All this presupposes the software uses these UART features, prior to
WfW3.11, this was not the case at an OS level, so that demand for
buffered UARTs was slow, until V.32bis made it desirable and V.34
makes it almost essential (someone is gonna post that thier V.34
doesn't need it <g> )
>)There's no reason a 16450 (or 8250) UART can't be run at 115,200 bps
>)as long as no Windows or other multitasking nonsense is going on.
Remember IDE block mode - longer periods with disabled interrupts
>There's no reason a 16450 or 8250 can't be run at 115,200 EVEN IF
>multitasking is going on.
>Well written operating systems don't disable interrupts in a way that
>would interfere with serial I/O like this for the lengths of time that
>would cause troubles. They only disable the interrupts which might
>interfere with whatever is going on at the moment.
But nothing likes being interrupted 10x (or more) often that
necessary; that alone makes buffered UARTs desirable.
Cory Martin SELIGMAN
"B.MacDonald" <bu...@nthwd.demon.co.uk> writes:
>>Hogwash. You obviously are not an expert on the 8250. I have regularly
>>run the 8250 at 115200 baud, and not missed a character, on XT class
>>machines (with 8088s in them, not even 8086s). They -were- 10 MHz
>>machines, however.
>Why are you responding to these postings? You haven't the faintest idea
>what you are talking about.
>Paul is exactly right. The only way you could have operated at 115k
>without overun errors is:
>* if you were using an internal modem which, by the way, usually have a
>16550A chip (or equivalent emulator) built-in.
>* or your setup (or a low speed modem - eg, 2400 baud) pegged your
>connection (ie, line speed) at a suitably low level... in which case
>setting your internal serial speed to 115k was pointless.
>* or in your dreams.
i have regularly managed 115k transfers between an ancient XT (8MHz) and
a 386. neither had 16550 UARTs or even 16450.
the XT has a 8250. I checked it. the 386 had a multi-I/O card with
everything on one chip, which reported that it had an 8250 to all the
software that I ever tried it with.
I had true 115k bps transfers., with several programs (xtlink, procomm
plus, telemate) over a five wire null modem cable. Never got an error.
No internal modem (no modem at all)
not pegged down to anyting slower
not DREAMING.
the 8250, 16450, 16550 can all run at the same maximum bit rate. the biggest
difference is in the buffering, and on an MSDOS machine, running only a
decent comms program, the required buffering is minimal.
don't quote theoretical crap that yopu read in the FAQs unless you've TRIED IT
OUT.
Perry Grieb
In article <5edsqo$1i8...@news.inlink.com>, hins...@inlink.com (Paul Hustava) writes:
> In article <5e7urh$s...@crcnis3.unl.edu>, obi...@engrs.unl.edu (Marc Lombardo) wrote:
>
> I did a little research on this last part, and apparently the 8250 (not the
> 8250A or 8250B) has a bug that was never really fixed, but BIOS's were
> written to deal with the bug. The clincher here is that if the BIOS was
> replaced without replacing the UART (or vice versa) the bug would rear it's
> ugly head, and the data transmission errors would appear.
>
> Paul Hustava
> hins...@inlink.com
The PC BIOS calls poll the UART. It's a very poor device driver
design. IBM (and/or MS) should have been shot for this design.
To use a PC UART you need to have an interrupt driven device
driver. There is a MS-DOS based fossil UART driver called X00
that actually works. Most (DOS) communications programs have
their own interrupt routine that hooks the correct IRQ. Other
OS's (I don't know about MS Windows products) "do it right" as
far as I know. The X00 author has a UART driver for OS/2 also.
Conclusion: NEVER use a polled pc BIOS to talk to a UART.
You want / need to use interrupts and hardware flow control.
This is a "major software design bug" and it really doesn't
matter which part (8250 .vs. 16450 .vs. 16550) you use.
Perry Grieb
c23...@eng.delcoelect.com
--
Perry Grieb
c23...@eng.delcoelect.com
John Baur
Marc Lombardo wrote:
Just to clear up some facts about UARTS,
> will upgrading to a 16550 UART allow me to use my tsrs and still achieve
> the same, or just about the same transfer rates?
The 16550 UART is supposed to be a buffered UART, but it has a bug in
the buffer.
It will therefore achieve nothing in comparison to an 8250 other than
giving you
a scratch register which is in fact a pretty useless byte of RAM.
The 16550a however is the bug fixed version - this will allow certain
software to
use the hardware buffer (Software running under windows and using
windows for
comms access will use the FIFO (First In First Out) buffer) Older Dos
based
applications will not.
>
> will upgrading to a 16550 uart allow me to achieve fast transfer rates even
> when i'm in windows?
>
So the answere is YES, using a 16550a in windows base applications will
reduce
overrun errors, and achieve faster transfer rates.
B.MacDonald
In article <5ej4d2$4...@mulga.cs.mu.OZ.AU>, Cory Martin SELIGMAN
<cor...@cat.cs.mu.OZ.AU> writes
>i have regularly managed 115k transfers between an ancient XT (8MHz) and
>a 386. neither had 16550 UARTs or even 16450.
>
>I had true 115k bps transfers., with several programs (xtlink, procomm
>plus, telemate) over a five wire null modem cable. Never got an error.
>
>the 8250, 16450, 16550 can all run at the same maximum bit rate. the biggest
>difference is in the buffering, and on an MSDOS machine, running only a
>decent comms program, the required buffering is minimal.
>
That's all very impressive and just goes to show that you you do almost
anything with some lamp cord and a pocket calculator.
However, the question was asked in the context of a normal (modern)
user, running Windows, who was having problems with overrun errors. In
the context in which Paul asked his question, I believe my posting
remains valid.
>don't quote theoretical crap that yopu read in the FAQs unless you've TRIED IT
>OUT.
>
>cor...@students.cs.mu.oz.au
^^^^^^^^
AHHH, The angst of youth.
Perhaps in a few years you will realize that other people have also been
around and achieved a few things for themselves. And that occaisionally
what they say may be different, but of value nevertheless. :o)
Roeland Th. Jansen
In comp.dcom.modems Perry Grieb <c23...@mail.delcoelect.com> wrote:
> design. IBM (and/or MS) should have been shot for this design.
IBM only.
> matter which part (8250 .vs. 16450 .vs. 16550) you use.
start with the hardware conclusion. the peope defining this serial port
nobody heard of until the PC got along, should be shot on the spot.
there were good and fast alternatives but IBM made one of the many classic
mistakes.
--
Grobbebol's Home (Linux 2.0.xx i586)
Peter H. Granzeau
On Fri, 21 Feb 1997 10:27:43 +0200, John Baur <joh...@ilink.nis.za>
wrote:
>Just to clear up some facts about UARTS,
>
>> will upgrading to a 16550 UART allow me to use my tsrs and still achieve
>> the same, or just about the same transfer rates?
>
>The 16550 UART is supposed to be a buffered UART, but it has a bug in
>the buffer.
Und so weiter.
Where, in the past 5 years, have you found a 16550 for sale?
Mike McCarty
Cory, I know that you are not disagreeing with me. This is the first
that I saw B.MacDonald's post, and am replying to him via you.
Pardon please?
In article <5ej4d2$4...@mulga.cs.mu.OZ.AU>,
Cory Martin SELIGMAN <cor...@cat.cs.mu.OZ.AU> wrote:
)"B.MacDonald" <bu...@nthwd.demon.co.uk> writes:
)
)>>Hogwash. You obviously are not an expert on the 8250. I have regularly
)>>run the 8250 at 115200 baud, and not missed a character, on XT class
)>>machines (with 8088s in them, not even 8086s). They -were- 10 MHz
)>>machines, however.
)
)>Why are you responding to these postings? You haven't the faintest idea
)>what you are talking about.
)
)>Paul is exactly right. The only way you could have operated at 115k
)>without overun errors is:
MacDonald:
Since you have not contacted me and asked me what I did, then you do
-not- know what I did.
None of your conjectures is correct. Not-even-one.
I am a senior software engineer at DSC communications corporation. I
have been writing real-time operating system code for over 12 years. I
have designed and written an entire multi-tasking operating system. I
first programmed the 8250 chip in 1982, and used 16 of them with an 8085
running at 5 MHz using the multi-tasking operating system mentioned
above.
I submit that -you- are the one who does not know what he is talking about.
)>* if you were using an internal modem which, by the way, usually have a
)>16550A chip (or equivalent emulator) built-in.
No, I used a serial interface board with an 8250 chip plainly visible on
it in both XT machines. When I did this the first time, the 16550 was
not yet designed.
)>* or your setup (or a low speed modem - eg, 2400 baud) pegged your
)>connection (ie, line speed) at a suitably low level... in which case
)>setting your internal serial speed to 115k was pointless.
)>* or in your dreams.
I was not using a modem at all. I was using direct serial links.
Furthermore, I am talking about sustained 115200 bps. Not running at
115200 baud, with octets being transmitted/received at a typist's rate.
I am talking about pure machine-level binary communications with 8 bit
data, 1 start, 1 stop, no parity, or 11520 octets per second sustained
transfer rate. I transmitted millions of octets without pause directly
from one machine to another. The source was a disc drive, which had NO
PROBLEM keeping up with the demand. And we timed the transfers for a few
tests of a few megabytes of data, to ensure that we were running at full
data rates.
I suggest that, before you post again, you learn something about real
time control of hardware. At the moment, you seem to know less than
nothing, since the little bit you -think- you know is incorrect.
)i have regularly managed 115k transfers between an ancient XT (8MHz) and
)a 386. neither had 16550 UARTs or even 16450.
)
)the XT has a 8250. I checked it. the 386 had a multi-I/O card with
)everything on one chip, which reported that it had an 8250 to all the
)software that I ever tried it with.
)
)I had true 115k bps transfers., with several programs (xtlink, procomm
)plus, telemate) over a five wire null modem cable. Never got an error.
)
)No internal modem (no modem at all)
)
)not pegged down to anyting slower
)
)not DREAMING.
)the 8250, 16450, 16550 can all run at the same maximum bit rate. the biggest
Ummm, not quite true, Cory. It is true that with a 1.8432 MHz clock,
the maximum bit rate is 115200 bps, no matter what the chip (even
non-National Semiconductor with 1/16 clock rates). And that is the only
one used with standard serial interfaces available on the IBM PC
compatible machines.
BUT, the 8250 and 16450 support up to 3.1 MHz baud clocks (bit rates of
193750 bps max.) while the 16550 allows the use of up to 8 MHz baud
clocks (500000 bps max).
)difference is in the buffering, and on an MSDOS machine, running only a
)decent comms program, the required buffering is minimal.
)
)don't quote theoretical crap that yopu read in the FAQs unless you've TRIED IT
)OUT.
)
)cor...@students.cs.mu.oz.au
Yes, it's much better to quote real iformation from manufacturer's data
sheets (see DATA COMMUNICATIONS/LOCAL AREA NETWORKS/UARTS Handbook
published by National Semiconductor page 4-6 for the 3.1 MHz spec. on
the 8250, page 4-22 for the 3.1 MHz spec. on the 16450, and page 4-39
for the 8 MHz spec. on the 16550), and real life experience controlling
hardware yourself.
And umm.... Thanks, Cory.
Chris Quirke
jmcc...@sun1307.spd.dsccc.com (Mike McCarty) wrote:
>Cory Martin SELIGMAN <cor...@cat.cs.mu.OZ.AU> wrote:
>)"B.MacDonald" <bu...@nthwd.demon.co.uk> writes:
<various inter-meatware ego-negotiations snipped>
>)>> I have regularly run the 8250 at 115200 baud, and not missed a
>)>> character, on XT class machines (with 8088s in them, not even
>)>> 8086s). They -were- 10 MHz machines, however.
>Furthermore, I am talking about sustained 115200 bps. Not running at
>115200 baud, with octets being transmitted/received at a typist's rate.
>)i have regularly managed 115k transfers between an ancient XT (8MHz) and
>)a 386. neither had 16550 UARTs or even 16450.
>)the XT has a 8250. I checked it. the 386 had a multi-I/O card with
>)everything on one chip, which reported that it had an 8250 to all the
>)software that I ever tried it with.
>)I had true 115k bps transfers., with several programs (xtlink, procomm
>)plus, telemate) over a five wire null modem cable. Never got an error.
I agree, the "problem" with older UARTs does not seem to be at the raw
baud rate level at all. So it doesn't suprise me at all that you can
stream data between fast (i.e. non-IBM) XTs in a non-multitasking,
single-foreground-application environment; I've done that as well,
using a terminal saturation tester written in assembler that uses the
UART at the port level, bypassing the brain-dead BIOS routines.
Your mileage will vary horrendously once you introduce delays in
interrupt service caused by longish disabled-interrupt spells or
general software activity bloat.
The converse is also true; if you are running such data streaming as a
background task, the overhead of an interrupt call for each byte will
have more impact on foreground application performance.
>------------ --- -- - - - - -
You folks are jacked on UARTs etc., perhaps you can answer a lifelong
puzzle for me. Why does it take a modem and attendant software
several seconds to transfer and process about 60 bytes of AT commands?
If I have to scramble a fax reception app for an incoming call, the
setup session takes so long the call is often lost...
Elder, Eric
Chris Quirke wrote:
>
> You folks are jacked on UARTs etc., perhaps you can answer a lifelong
> puzzle for me. Why does it take a modem and attendant software
> several seconds to transfer and process about 60 bytes of AT commands?
>
> If I have to scramble a fax reception app for an incoming call, the
> setup session takes so long the call is often lost...
Why not load your fax manager into memory? You can receive faxes
unattended. Otherwise, when you load the fax manger manually, the modem
must be initilized first. This will normally take 10-15 seconds.
Geoffrey Welsh
>You folks are jacked on UARTs etc., perhaps you can answer a lifelong
>puzzle for me. Why does it take a modem and attendant software
>several seconds to transfer and process about 60 bytes of AT commands?
It looks like modems delay sending their response codes, probably to
deal with now-rare brain-dead systems that can't receve data right
after sending. The USR Courier has the option to disable this delay,
and I've used it... one installation that I set up has software that
can leave the modem in any one of several states of configuration,
depending...), so I have the software configured to send three fairly
lengthy commands to completely reconfigure the modem before giving the
answer command (i.e., "ATA" is the fourth - and by far the shortest -
command) following a RING result code from the modem... and it
completes this before the second RING. Does that seem like an
exception to your observation that most modems take "several seconds
to transfer and process about 60 bytes of AT commands?"
--
Geoffrey Welsh, MIS Co-ordinator, InSystems Technologies (gwe...@insystems.com)
At home: xenitec.on.ca!zswamp!geoff; Temporary: crs...@inforamp.net
"It ain't broke... it just lacks duct tape!" - Heard on the radio
doug haire
Cory Martin SELIGMAN (cor...@cat.cs.mu.OZ.AU) wrote:
: "B.MacDonald" <bu...@nthwd.demon.co.uk> writes:
:
: >>Hogwash. You obviously are not an expert on the 8250. I have regularly
: >>run the 8250 at 115200 baud, and not missed a character, on XT class
: >>machines (with 8088s in them, not even 8086s). They -were- 10 MHz
: >>machines, however.
:
: >Why are you responding to these postings? You haven't the faintest idea
: >what you are talking about.
:
: >Paul is exactly right. The only way you could have operated at 115k
: >without overun errors is:
: >* if you were using an internal modem which, by the way, usually have a
: >16550A chip (or equivalent emulator) built-in.
: >* or your setup (or a low speed modem - eg, 2400 baud) pegged your
: >connection (ie, line speed) at a suitably low level... in which case
: >setting your internal serial speed to 115k was pointless.
: >* or in your dreams.
:
: i have regularly managed 115k transfers between an ancient XT (8MHz) and
: a 386. neither had 16550 UARTs or even 16450.
:
: the XT has a 8250. I checked it. the 386 had a multi-I/O card with
: everything on one chip, which reported that it had an 8250 to all the
: software that I ever tried it with.
:
: I had true 115k bps transfers., with several programs (xtlink, procomm
: plus, telemate) over a five wire null modem cable. Never got an error.
:
: No internal modem (no modem at all)
:
: not pegged down to anyting slower
:
: not DREAMING.
:
: the 8250, 16450, 16550 can all run at the same maximum bit rate. the biggest
: difference is in the buffering, and on an MSDOS machine, running only a
: decent comms program, the required buffering is minimal.
:
: don't quote theoretical crap that yopu read in the FAQs unless you've TRIED IT
: OUT.
:
: cor...@students.cs.mu.oz.au
I have tried this out. It failed to transfer without error. I ran it with
two DOS machines running DSZ's zmodem. One machine was an AMD 486dx4/100,
the other was a 486sx33. Both machines had 16550a's. Errors were fairly
regular. When I booted one machine to linux, that machine received data
all the way up to 115200 bps without a single error.
Additionally, when I ran my BBS (which I did for 7 years), I had no
trouble using a 16450 UART into a V.32bis modem under DOS and PcBoard at
first. After awhile, as PcBoard became more complex and ate up more
memory, I was forced up to a 16550a in order to eliminate errors on
receive (never have had a problem transmitting).
When you people say you ran a 8088/8086 with an 8250 and a null modem
cable and transferred at 115200 without error, I say you are telling a
*huge* fib.
--
[[ my actual login name is dhaire, not d.haire ]]
B.MacDonald
In article <5f4ca3$120c$4...@news.gate.net>, doug haire <d.h...@gate.net>
writes
> After awhile, as PcBoard became more complex and ate up more
>memory, I was forced up to a 16550a in order to eliminate errors on
>receive (never have had a problem transmitting).
>
>When you people say you ran a 8088/8086 with an 8250 and a null modem
>cable and transferred at 115200 without error, I say you are telling a
>*huge* fib.
>
People interested in serial port buffering, which has been discussed in
such a continuing and lively manner in this thread, should check out
Technical Note 550 in the FAQ section of the US Robotics website at
www.usr.com
Mike McCarty
In article <5f4ca3$120c$4...@news.gate.net>, doug haire <d.h...@gate.net> wrote:
)I have tried this out. It failed to transfer without error. I ran it with
)two DOS machines running DSZ's zmodem. One machine was an AMD 486dx4/100,
)the other was a 486sx33. Both machines had 16550a's. Errors were fairly
)regular. When I booted one machine to linux, that machine received data
)all the way up to 115200 bps without a single error.
)
)Additionally, when I ran my BBS (which I did for 7 years), I had no
)trouble using a 16450 UART into a V.32bis modem under DOS and PcBoard at
)first. After awhile, as PcBoard became more complex and ate up more
)memory, I was forced up to a 16550a in order to eliminate errors on
)receive (never have had a problem transmitting).
)
)When you people say you ran a 8088/8086 with an 8250 and a null modem
)cable and transferred at 115200 without error, I say you are telling a
)*huge* fib.
Well, I resent that.
I am a senior software engineer at DSC Communications Corporation. I
wrote my first multitasking operating system in 1983 or thereabouts. I
have been doing real-time work since 1982 or thereabouts. How long have
you been doing real-time operating systems? How many operating systems
have you worked on? How many have you written?
I think you need to put a curb on your tongue.
The fact of the matter is, you didn't use the programs I used to do the
transfers. You used DSZ's zmodem. I have no idea how well written that
program is, but I suggest you try this.
Install INTERLNK/INTERSVR on your machines, and copy a file of a few
megabytes across the serial link. Then do some simple arithmetic, like
division.
Then come back here and apologize.
INTERLNK/INTERSVR work quite well at these rates in my experience.
Now consider this, mister smart-mouth. At 115200 baud, with 8 bits, no
parity, one stop (and one start), that's one interrupt every 87
microseconds (well, 86.805..). With a 100 MHz 486, with an (estimated) 4
cycles per instruction, that's 25 million instructions/second, or 25 per
microsecond. That comes out to about 2000 instructions (2170, but I'm
not going to claim that level of accuracy).
Anyone who can't handle one interrupt per 2000 instructions isn't doing
a very good job managing time.
Try engaging your brain before starting your mouth, next time.
John A. Limpert
On 27 Feb 1997 16:21:23 GMT, d.h...@gate.net (doug haire) wrote:
>When you people say you ran a 8088/8086 with an 8250 and a null modem
>cable and transferred at 115200 without error, I say you are telling a
>*huge* fib.
Why? There is no technical reason why an 8088/8086 can't keep up with
115,200 bps on an 8250 or 16450 if the software is properly designed.
What will kill you is software in the operating system or BIOS that
disables interrupts for lengthy periods of time. Many older video
drivers used to disable interrupts while waiting for horizontal
retrace to occur. Disk drivers also caused problems by disabling
interrupts during data transfers. MS DOS and various TSRs are infamous
for disabling interrupts for a long time.
Back when real programmers wrote operating systems, the operating
system and device drivers had a maximum interrupt latency
specification and the programmer was responsible for ensuring that
interrupts were not disabled for more than N cpu cycles or
microseconds.
There is no excuse for the inability of many PC operating systems to
keep up with 115,200 bps on an 8250/16450.
John A. Limpert
jo...@Radix.Net
doug haire
John A. Limpert (jo...@Radix.Net) wrote:
: On 27 Feb 1997 16:21:23 GMT, d.h...@gate.net (doug haire) wrote:
:
: >When you people say you ran a 8088/8086 with an 8250 and a null modem
: >cable and transferred at 115200 without error, I say you are telling a
: >*huge* fib.
:
: Why? There is no technical reason why an 8088/8086 can't keep up with
: 115,200 bps on an 8250 or 16450 if the software is properly designed.
First, you try to say there's no reason that it couldn't... then you start
explaining why it couldn't...
: What will kill you is software in the operating system or BIOS that
: disables interrupts for lengthy periods of time. Many older video
: drivers used to disable interrupts while waiting for horizontal
: retrace to occur. Disk drivers also caused problems by disabling
: interrupts during data transfers. MS DOS and various TSRs are infamous
: for disabling interrupts for a long time.
:
: Back when real programmers wrote operating systems, the operating
: system and device drivers had a maximum interrupt latency
: specification and the programmer was responsible for ensuring that
: interrupts were not disabled for more than N cpu cycles or
: microseconds.
MS/PC-DOS was not written with an eye toward high speed serial port
communications nor was teh PC designed, hardware-wise, with that in mind.
The serial port was seen more as a printer access than as a gateway to a
telecommunications. The highest speed dial-up at that time was 1200 bps
with 2400 bps still not available.
We live in the real world, not the theoretical one, though so why anyone
have designed a system for high speed serial communication when there was
none available or even being considered?
: There is no excuse for the inability of many PC operating systems to
: keep up with 115,200 bps on an 8250/16450.
Hardware limitations (the 16450 didn't come out when the PC first arrived,
it was later), lack of foresight of what data communications would become
in 12-15 years (not exactly a failing, I doubt you were expecting 28.8k in
1983), lack of a need to consider it.
Ray Gannon
jmcc...@sun1307.spd.dsccc.com (Mike McCarty) wrote:
>In article <5f4ca3$120c$4...@news.gate.net>, doug haire <d.h...@gate.net> wrote:
>>)
>)cable and transferred at 115200 without error, I say you are telling a
>)*huge* fib.
>
>Well, I resent that.
......Discussion deleted........
>Try engaging your brain before starting your mouth, next time.
>
>Mike
Well said, Mike. I've run 8086's at 115 KBaud before now. It all depends
on the quality of the software, and whether you're using a sensible
quality RS-232 cable.
Ray
doug haire
Mike McCarty (jmcc...@sun1307.spd.dsccc.com) wrote:
: In article <5f4ca3$120c$4...@news.gate.net>, doug haire <d.h...@gate.net> wrote:
: )two DOS machines running DSZ's zmodem. One machine was an AMD 486dx4/100,
: )the other was a 486sx33. Both machines had 16550a's. Errors were fairly
: )regular. When I booted one machine to linux, that machine received data
: )all the way up to 115200 bps without a single error.
: )
: )Additionally, when I ran my BBS (which I did for 7 years), I had no
: )trouble using a 16450 UART into a V.32bis modem under DOS and PcBoard at
: )first. After awhile, as PcBoard became more complex and ate up more
: )memory, I was forced up to a 16550a in order to eliminate errors on
: )receive (never have had a problem transmitting).
: )When you people say you ran a 8088/8086 with an 8250 and a null modem
: )cable and transferred at 115200 without error, I say you are telling a
: )*huge* fib.
:
: Well, I resent that.
: I am a senior software engineer at DSC Communications Corporation. I
: wrote my first multitasking operating system in 1983 or thereabouts. I
: have been doing real-time work since 1982 or thereabouts. How long have
: you been doing real-time operating systems? How many operating systems
: have you worked on? How many have you written?
We're not talking about whatever operating system you may have written. We
are talking about the existing, commonly-used, operating systems and
existing, commonly-used, hardware.
I told you my experiences, I satnd by what I said.
: I think you need to put a curb on your tongue.
Curb your own. I made no false statements. It seems that you are offended
because I challenged your assertion. Life is cruel.
: The fact of the matter is, you didn't use the programs I used to do the
: transfers. You used DSZ's zmodem. I have no idea how well written that
: program is, but I suggest you try this.
Here we go changing the environment. The environment is DOS (MS or PC) and
the hardware is Intel 8086/8088 at 10 Mhz or less and an 8250 UART.
*You* try it and then come back and tell me what you can or cannot do.
: Install INTERLNK/INTERSVR on your machines, and copy a file of a few
: megabytes across the serial link. Then do some simple arithmetic, like
: division.
No, I won't. I orefer to stick with the existing real-world choices of
environment which is what the issue is about. The 8250 UART is inadequate
for use with a PC XT, MS/PC-DOS, and a 28.8K modem.
You have an argument for that?
: Then come back here and apologize.
I wouldn't hold my breath waiting on this apology if I were you.
: INTERLNK/INTERSVR work quite well at these rates in my experience.
And is not relevant to the discussion.
: Now consider this, mister smart-mouth. At 115200 baud, with 8 bits, no
: parity, one stop (and one start), that's one interrupt every 87
: microseconds (well, 86.805..). With a 100 MHz 486, with an (estimated) 4
: cycles per instruction, that's 25 million instructions/second, or 25 per
: microsecond. That comes out to about 2000 instructions (2170, but I'm
: not going to claim that level of accuracy).
Where's the 8086/8088? That was the original claim.
: Anyone who can't handle one interrupt per 2000 instructions isn't doing
: a very good job managing time.
:
: Try engaging your brain before starting your mouth, next time.
Thank you for showing that people who cannot stick to the existing issue
and are caught making false claims simple resort to insults and red
herrings to overcome their embarrassment.
--
John A. Limpert
On 28 Feb 1997 13:20:25 GMT, d.h...@gate.net (doug haire) wrote:
>John A. Limpert (jo...@Radix.Net) wrote:
>: Why? There is no technical reason why an 8088/8086 can't keep up with
>: 115,200 bps on an 8250 or 16450 if the software is properly designed.
>
>First, you try to say there's no reason that it couldn't... then you start
>explaining why it couldn't...
The point was that there is nothing in the hardware design of the PC
that keeps it from running a 8250/16450 at 115,200 bps. Even with the
poorly written software in the BIOS and many operating systems there
are some workarounds:
1. Don't display anything on the screen using the operating system or
BIOS.
2. Use large buffers for disk I/O and only read/write the disk when
the remote system is waiting for a response.
3. Disable interrupts while sending/receiving packets. The CPU sits in
a loop polling UART status while sending/receiving a packet. This
technique is used in some laplink style programs. It works nicely with
XMODEM style protocols that send fixed length packets and single
characters for ACK/NAK/control.
>We live in the real world, not the theoretical one, though so why anyone
>have designed a system for high speed serial communication when there was
>none available or even being considered?
There were other applications for serial ports besides printers and
dialup modems. Terminal emulation, file transfer and networking via
hard-wired serial line (UUCP/SLIP) were not uncommon. There were tape
drives and disk drives that used the serial port for an interface. I
wrote software for the original 4.77 MHz 8088 based IBM PC that
communicated over 9.6/56/224 kbps synchronous data lines.
>: There is no excuse for the inability of many PC operating systems to
>: keep up with 115,200 bps on an 8250/16450.
>
>Hardware limitations (the 16450 didn't come out when the PC first arrived,
>it was later), lack of foresight of what data communications would become
>in 12-15 years (not exactly a failing, I doubt you were expecting 28.8k in
>1983), lack of a need to consider it.
I still think it is largely a matter of sloppy programming by IBM,
Microsoft and numerous OEMs, with a bit of bad hardware design thrown
in. I've seen and written enough software for the PDP-11, 6502, Z-80,
680X0 and 80X86 to know that the need for the 16550A was created by
the incompetence of Microsoft and other software vendors. Serial ports
were being run at 38,400 bps, without errors, using standard UART
chips, back in 1980 on systems that were hundreds, if not thousands of
times slower than a modern Wintel box. I have never understood why
Microsoft, with all of their money and programming talent, has done
such a crappy job of writing operating systems.
John A. Limpert
jo...@Radix.Net
doug haire
John A. Limpert (jo...@Radix.Net) wrote:
:
: >John A. Limpert (jo...@Radix.Net) wrote:
: >: Why? There is no technical reason why an 8088/8086 can't keep up with
: >: 115,200 bps on an 8250 or 16450 if the software is properly designed.
: >
: >First, you try to say there's no reason that it couldn't... then you start
: >explaining why it couldn't...
:
: The point was that there is nothing in the hardware design of the PC
: that keeps it from running a 8250/16450 at 115,200 bps. Even with the
: poorly written software in the BIOS and many operating systems there
: are some workarounds:
The PC XT was quite limited. And, by operating system design, limited port
speed to 9600 bps. This was presumed adequate, I suppose, at the time
since there wasn't anything really operating faster than this on a regular
basis. Even Unix systems were communicating at that speed at the fastest
over leased line (4 wire). It wasn't until a few years later that this
speed was achieved in dialup modems.
: 1. Don't display anything on the screen using the operating system or
: BIOS.
Display interaction was one of the design problems interfering with good
serial communications. I think you just disproved your own premise...
: 2. Use large buffers for disk I/O and only read/write the disk when
: the remote system is waiting for a response.
DSZ used (and uses) a 1k buffer and has numerous handshaking options, one
of which ("slow") allows for latency in disk writes. That was fairly
innovative in file transfer protocols and did not exist in the early days
of the PC XT. In fact, there were few streaming protocols at all and most
used ACK/NAK Xmodem and then Ymodem... neither of which have buffers of
any size.
: 3. Disable interrupts while sending/receiving packets. The CPU sits in
: a loop polling UART status while sending/receiving a packet. This
: technique is used in some laplink style programs. It works nicely with
: XMODEM style protocols that send fixed length packets and single
: characters for ACK/NAK/control.
Yes, dedicating the CPU to handling the serial port and doing absolutely
nothing except as subordinate to that would work. That isn't the real
world. We aren't talking about dedicating the system to be a
transmitter/receiver, we are talking about the PC XT in the real world and
what software people would use for a multitude of purposes involving
telecommunications (interfacing with modems, not acting as an extension of
another machine via its serial port).
: >We live in the real world, not the theoretical one, though so why anyone
: >have designed a system for high speed serial communication when there was
: >none available or even being considered?
:
: There were other applications for serial ports besides printers and
: dialup modems. Terminal emulation, file transfer and networking via
: hard-wired serial line (UUCP/SLIP) were not uncommon. There were tape
: drives and disk drives that used the serial port for an interface. I
: wrote software for the original 4.77 MHz 8088 based IBM PC that
: communicated over 9.6/56/224 kbps synchronous data lines.
Terminal emulation was a enhancement to the PC XT but, when it first came
out, it was limited to TTY, VT-100, and ANSI-BBS (a variation of VT-100).
Later, Wyse terminal and others were added as the needs arose and demand
increased. Most businesses purchased terminals for communicating with
mini-computers and mainframes and did see the need to use a PC as a
"smart" terminal. UUCP was not available when the XT first came out (not
for DOS anyway, Unix had been using it for some time), there were tape
drives (cassette recorders ala Radio Shack ) which were used and operated
at much slower than 115200. No SLIP was available at that time.
Let's stick to the realities of the PC XT and the 8250 and the environment
it was designed to function in.
: >: There is no excuse for the inability of many PC operating systems to
: >: keep up with 115,200 bps on an 8250/16450.
: >
: >Hardware limitations (the 16450 didn't come out when the PC first arrived,
: >it was later), lack of foresight of what data communications would become
: >in 12-15 years (not exactly a failing, I doubt you were expecting 28.8k in
: >1983), lack of a need to consider it.
:
: I still think it is largely a matter of sloppy programming by IBM,
: Microsoft and numerous OEMs, with a bit of bad hardware design thrown
: in. I've seen and written enough software for the PDP-11, 6502, Z-80,
: 680X0 and 80X86 to know that the need for the 16550A was created by
: the incompetence of Microsoft and other software vendors. Serial ports
: were being run at 38,400 bps, without errors, using standard UART
: chips, back in 1980 on systems that were hundreds, if not thousands of
: times slower than a modern Wintel box. I have never understood why
: Microsoft, with all of their money and programming talent, has done
: such a crappy job of writing operating systems.
I cannot argue with you about the sloppy programming but I don't think
that was the entire story. They even have some excuses, which I pointed
out and you seem to want to ignore, for writing things the way they did.
The 286's were the rage when V.32 modems became affordable and speeds of
9600 bps and above started to be widespread. The 82450 (with a 3 byte
buffer) came out but was ignored by protocol writers. The 16550 came out
and helped solve the problems of dropped characters because of interrupt
latency problems. In other words, new hardware made up for the limitations
inherent in the design of the existing hardware.
Which brings us around to the beginning issue --
The PC XT and an 8250 running DOS and I don't care what DOS protocol
driver you use will have problems at high speed. Now, if your argument is
that software could have been written to overcome these hardware
limitations and wish to point to LapLink as an example then I will agree.
But no one was using LapLink to talk to modems, it was specialized piece
of software for a limited purpose.
Anthony Hill
On 28 Feb 1997 17:33:50 GMT, d.h...@gate.net (doug haire) wrote:
>Mike McCarty (jmcc...@sun1307.spd.dsccc.com) wrote:
<snip>
>: The fact of the matter is, you didn't use the programs I used to do the
>: transfers. You used DSZ's zmodem. I have no idea how well written that
>: program is, but I suggest you try this.
>
>Here we go changing the environment. The environment is DOS (MS or PC) and
>the hardware is Intel 8086/8088 at 10 Mhz or less and an 8250 UART.
>
>*You* try it and then come back and tell me what you can or cannot do.
>
>: Install INTERLNK/INTERSVR on your machines, and copy a file of a few
>: megabytes across the serial link. Then do some simple arithmetic, like
>: division.
>
>No, I won't. I orefer to stick with the existing real-world choices of
>environment which is what the issue is about. The 8250 UART is inadequate
>for use with a PC XT, MS/PC-DOS, and a 28.8K modem.
>
>You have an argument for that?
He already gave you one. Interlnk/intersvr are part of DOS
6.xx. The problem is NOT the hardware, or the OS. The only problem
is the way that the majority of software handles comm routines, which
is by using interupts (and this includes DSZ BTW, although that
program is quite good at how it handles interupts, it can run a 28.8
modem with no errors with a 8250 UART on a 386 or faster under some
conditions). Most software uses interupts for a number of reasons,
although probably most importantly because it's pretty much required
if you're going to do any sort of multitasking. I have yet to come
across a real term program that used anything other than interupts to
get data from the serial ports, but it can be done the same way that
some other software does it, but constantly polling the port to see if
any new data has arrived.
Anthony Hill | Sig files? SIG FILES?! What the
ah...@travel-net.com | hell do I need a sig file for?!
Mike McCarty
In article <5f6m2p$47g$2...@news.gate.net>, doug haire <d.h...@gate.net> wrote:
)John A. Limpert (jo...@Radix.Net) wrote:
): On 27 Feb 1997 16:21:23 GMT, d.h...@gate.net (doug haire) wrote:
):
): >When you people say you ran a 8088/8086 with an 8250 and a null modem
): >cable and transferred at 115200 without error, I say you are telling a
): >*huge* fib.
):
): Why? There is no technical reason why an 8088/8086 can't keep up with
): 115,200 bps on an 8250 or 16450 if the software is properly designed.
)
)First, you try to say there's no reason that it couldn't... then you start
)explaining why it couldn't...
No, that is not what he did. He made two very different kinds of
statements. One about hardware, the other about software. You are
trying to draw some sort of connection between them.
[snip]
)MS/PC-DOS was not written with an eye toward high speed serial port
)communications nor was teh PC designed, hardware-wise, with that in mind.
)The serial port was seen more as a printer access than as a gateway to a
)telecommunications. The highest speed dial-up at that time was 1200 bps
)with 2400 bps still not available.
)
)We live in the real world, not the theoretical one, though so why anyone
)have designed a system for high speed serial communication when there was
)none available or even being considered?
Ok, how about some real-world computations? With an average of 8 cycles
per instruction (conservative estimate, I believe) on a 10 MHz 8088
(what I spec'ed when this started to become flames), and running 8
bits, no parity, one stop, at 115200 baud we have
10 bits per interrupt
87 microseconds per interrupt
1.25 instructions per microsecond
~110 instructions per interrupt
That is not only doable, I have -done- it on a 10 MHz XT running MSDOS.
Those chips are very simple, and require very few instructions to
manipulate. I have transferred megabytes of data without missing a
single octet. Of course, it requires double buffering and other time
saving techniques.
So nobody was doing high speed serial transmission in 1980? I suppose
you use a telephone? Did you use one in 1980? Did you know that in 1980,
call setup was already being done using 56 kilobaud connections in some
areas? Are you aware of SS7 or ESS signalling? Ever heard of T1 or T3
spans which use > 1 Megabit/second serial?
I'm afraid that you are displaying a rather wide range of ignorance. The
fact that the chip itself (the 8250) was spec'd to run at a maximum
clock rate of 3.1 MHz and with a divisor of 2 (though it can run with a
divisor of 1, just not spec'd for it) gave it a max. spec'd baud rate of
193750 baud ought to tell you that people had a NEED for such
communications rates.
): There is no excuse for the inability of many PC operating systems to
): keep up with 115,200 bps on an 8250/16450.
)
)Hardware limitations (the 16450 didn't come out when the PC first arrived,
)it was later), lack of foresight of what data communications would become
)in 12-15 years (not exactly a failing, I doubt you were expecting 28.8k in
)1983), lack of a need to consider it.
Au contraire. Peole were -aready using- 56 Kilobaud in 1983.
Ray
On 27 Feb 1997 16:21:23 GMT, doug haire <d.h...@gate.net> wrote:
>
>When you people say you ran a 8088/8086 with an 8250 and a null modem
Chalk up another fiber then. I've also done many file transfers
between a 8088 (actually NEC V20) and a 386sl (as well as a Pentium
75). The 8088 has a 8250 UART, the 386 has a 16450 and the pentuim
has both 16550 and 16650's. 115200 bps was no problem for small
transfers (say 1MB or less) on any of the systems but the 386 would
become a bit unreliable after several minutes of sustained 115200bps
transfers. In no case was the 8088/V20 ever a bottleneck. Most
transfers were done with Telix for Dos running under Dos or OS/2. The
only special tweaking to the 8088 was to turn off write caching and
set Telix's internal buffers to their minimum (1K).
--
Ray
rv1...@goodnet.com
doug haire
Ray (RV1...@goodnet.com) wrote:
Which unit was the receiving unit?
What cache was used (PC XT's did not come with cache software, that would
have been an add-on later)?
What version of DOS on the 8088? (It's obvious it wasn't running OS/2)
Were files compressed or uncompressed?
What protocol? I would presume, with Telix, that you were using zmodem but
I would like to verify.
What handshaking method used?
Ray
On 1 Mar 1997 19:16:47 GMT, doug haire <d.h...@gate.net> wrote:
>Ray (RV1...@goodnet.com) wrote:
>: Chalk up another fiber then. I've also done many file transfers
>: between a 8088 (actually NEC V20) and a 386sl (as well as a Pentium
>: 75). The 8088 has a 8250 UART, the 386 has a 16450 and the pentuim
>: has both 16550 and 16650's. 115200 bps was no problem for small
>: transfers (say 1MB or less) on any of the systems but the 386 would
>: become a bit unreliable after several minutes of sustained 115200bps
>: transfers. In no case was the 8088/V20 ever a bottleneck. Most
>: transfers were done with Telix for Dos running under Dos or OS/2. The
>: only special tweaking to the 8088 was to turn off write caching and
>: set Telix's internal buffers to their minimum (1K).
>
>Which unit was the receiving unit?
I did transfers in both directions.
>What cache was used (PC XT's did not come with cache software, that would
>have been an add-on later)?
I experimented with a program called "Cache86" on both the 8088 and
386. I didn't use it much with the 8088 but did use it for several
years on the 386. The 8088 wasn't a true XT but a home brew machine.
It actually had 1meg of memory but the last 3884k was only usefull as
a ram disk. It's only real purpose was to recieve faxes and provide
access to a 5-1/4" drive when I needed it.
>What version of DOS on the 8088? (It's obvious it wasn't running OS/2)
The 8088 had Dos 3.3 and the 386 had Dos 5.
>Were files compressed or uncompressed?
Mostly compressed.
>What protocol? I would presume, with Telix, that you were using zmodem but
>I would like to verify.
zmodem. I also used kermit on a few occasions.
>What handshaking method used?
mostly rts/cts although I experimented with xon/xoff as well.
--
Ray
rv1...@goodnet.com
doug haire
I cannot duplicate your error-free transfers. That doesn't mean you didn't
do them, it just means what it says. My bet is that your 8088 was using
an IDE drive and had VGA but I wouldn't swear to it. These things help
immensely but shouldn't allow the error free transfers.
My personal experience says it's not possible but yours does not. We
remain at an impass and should agree to disagree.
Ray (RV1...@goodnet.com) wrote:
--
Ray
On 2 Mar 1997 23:23:22 GMT, doug haire <d.h...@gate.net> wrote:
>I cannot duplicate your error-free transfers. That doesn't mean you didn't
>do them, it just means what it says. My bet is that your 8088 was using
>an IDE drive and had VGA but I wouldn't swear to it. These things help
>immensely but shouldn't allow the error free transfers.
No, just a ST506 (MFM) HD and ATI EGA card for video.
>My personal experience says it's not possible but yours does not. We
>remain at an impass and should agree to disagree.
Fair enough. If you are also using Telix, you could try enabling flow
control during disk writes. You might also try XON/XOFF if you think
there is a chance that either your cable or one of the ports isn't
properly handling RTS/CTS. Finally, if one of the machines in
question has buffered UARTs maybe you could disable the buffering on
that one as well.
If you or anyone else really needs or wants to get to the bottom of
this, I could put that machine back together and try to gather some
more data. The MB and cards are in a closet collecting dust and I'm
sure I have an extra power supply sitting around somewhere.
--
Ray
rv1...@goodnet.com
John Navas
[POSTED TO comp.dcom.modems]
"B.MacDonald" <bu...@nthwd.demon.co.uk> wrote:
>In article <5eata2$j...@sun001.spd.dsccc.com>, Mike McCarty <jmccarty@sun
>>Hogwash. You obviously are not an expert on the 8250. I have regularly
>>run the 8250 at 115200 baud, and not missed a character, on XT class
>>machines (with 8088s in them, not even 8086s). They -were- 10 MHz
>>machines, however.
>
>Why are you responding to these postings? You haven't the faintest idea
>what you are talking about.
>
>Paul is exactly right. The only way you could have operated at 115k
>without overun errors is:
>* if you were using an internal modem which, by the way, usually have a
>16550A chip (or equivalent emulator) built-in.
>* or your setup (or a low speed modem - eg, 2400 baud) pegged your
>connection (ie, line speed) at a suitably low level... in which case
>setting your internal serial speed to 115k was pointless.
>* or in your dreams.
>
>If you were running a high speed external modem wide open with a serial
>speed set at 115k, you would get overrun errors in short order, as the
>processor struggled to sort out the backlog of incoming data. With a
>10MHz processor, the effect would be even more pronounced. As the errors
>reached critical proportions, your download rate starts to drop off
>rapidly until you are receiving little if any incoming data.
Sorry, but I have to go with Mike on this one. I too have run an 8250A at
115.2 Kbps successfully on a 10 MHz XT -- I routinely used a serial link
to transfer data between two computers at that speed. The only caveat is
that I asserted flow control around disk writes (when not using a
ramdisk), and didn't do any multitasking.
--
Best regards,
John mailto:JNa...@NavasGrp.Dublin.CA.US http://www.aimnet.com/~jnavas/
28800 Modem FAQ: http://www.aimnet.com/~jnavas/modem/faq.html
Madis Kaal
In article <9Kr+6JAV...@nthwd.demon.co.uk>, "B.MacDonald" <bu...@nthwd.demon.co.uk>
<5eata2$j...@sun001.spd.dsccc.com> wrote:
>>)>will upgrading to a 16550 UART allow me to use my tsrs and still achieve
>>)>the same, or just about the same transfer rates?
>>)
>>)It will be much better with a 16550
>>
>>You don't know that. Does he have software which can properly utilize
>>the 16550?
>
>What sort of software might that be????
any software that turns on FIFO enable bits in UART and is designed to handle
multiple characters per interrupt. The problem with old software tended to be
the fact that the guys were using the contents of interrupt ID register for
jump table index. FIFO-ed UARTS use bits 6 and 7 of the same register for
chip ID which causes jumps to never-never land.
>>Hogwash. You obviously are not an expert on the 8250. I have regularly
>>run the 8250 at 115200 baud, and not missed a character, on XT class
>>machines (with 8088s in them, not even 8086s). They -were- 10 MHz
>>machines, however.
>
>Why are you responding to these postings? You haven't the faintest idea
>what you are talking about.
Well, you seems to have a faint idea (err... yeah, faint seems to be about
right).
here is what operating at 115200 is all about:
First of all, it does not really matter what UART you have. They can all pull
off 115200 physically. Handling the data with the software is a bit different
story.
at that baud rate you will have maximum 9216 interrupts per second and with
8250 UART you have to get the data out of the data register before the next
one is received - if you cant do that you will have overrun error. With 16550
you have 16-byte data queue which gives you 16 times more time to get to the
first byte and after you have started pulling data off the queue more bytes
can arrive so you may actually get something like 20 bytes per interrupt. This
is what helps you to avoid overrun errors. Now, even with FIFOs you may still
have problems depending on what you have to do with the data - disk writes,
network access and TSR-s may run significant amount of times with interrupts
disabled causing interrupt latency long enough to give you overruns even on
16-byte FIFOs.
Basically, you can either
a) use a fast enough machine to handle over 9000 interrupts per second
b) handle your data transfers in polled mode in reasonable chunks, with
interrupts disabled (that does not necessarily work under multitaskers).
>Paul is exactly right. The only way you could have operated at 115k
>without overun errors is:
>* if you were using an internal modem which, by the way, usually have a
>16550A chip (or equivalent emulator) built-in.
because of the reasons above, it does not really matter if you have internal
or external modem.
>* or your setup (or a low speed modem - eg, 2400 baud) pegged your
>connection (ie, line speed) at a suitably low level... in which case
>setting your internal serial speed to 115k was pointless.
this does not necessarily help either because if you 2400 bps modem gets a V42
or MNP data packet it will burst it all thru at 115200 bps possibly causing
like any other modem.
>The 16550 chip was an attempt to improve serial port throughput, but was
>not entirely successful. What is the industry standard now is actually
16550 was definately successful in impoving the allowed data rate and it had
the same 16 byte FIFO that later A chips have. The only problem was that the
FIFO logic did not quite work.
John Navas
[POSTED TO comp.dcom.modems]
ma...@forex.ee (Madis Kaal) wrote:
>First of all, it does not really matter what UART you have. They can all pull
>off 115200 physically. Handling the data with the software is a bit different
>story.
>
>at that baud rate you will have maximum 9216 interrupts per second and with
>8250 UART you have to get the data out of the data register before the next
>one is received - if you cant do that you will have overrun error. With 16550
>you have 16-byte data queue which gives you 16 times more time to get to the
>first byte and after you have started pulling data off the queue more bytes
>can arrive so you may actually get something like 20 bytes per interrupt.
Not unless your ISR is dog slow, in which case you have a serious problem
no matter what UART you have.
>because of the reasons above, it does not really matter if you have internal
>or external modem.
That depends. Some internal modems have "smart" UART's that completely
eliminate overrun.
Elder, Eric
Madis Kaal wrote:
>
> In article <9Kr+6JAV...@nthwd.demon.co.uk>, "B.MacDonald" <bu...@nthwd.demon.co.uk>
> <5eata2$j...@sun001.spd.dsccc.com> wrote:
> >>)>will upgrading to a 16550 UART allow me to use my tsrs and still achieve
> >>)>the same, or just about the same transfer rates?
> >>)
> >>)It will be much better with a 16550
> >>
> >>You don't know that. Does he have software which can properly utilize
> >>the 16550?
> >
> >What sort of software might that be????
>
> any software that turns on FIFO enable bits in UART and is designed to handle
> multiple characters per interrupt. The problem with old software tended to be
> the fact that the guys were using the contents of interrupt ID register for
> jump table index. FIFO-ed UARTS use bits 6 and 7 of the same register for
> chip ID which causes jumps to never-never land.
>
> >>Hogwash. You obviously are not an expert on the 8250.
A similar thread started on this topic about three weeks ago. I found
out the 8250 is capable of very high port speeds in DOS. In a Windows
enviroment, the 16550 is the UART of choice.
Chris Quirke
ma...@forex.ee (Madis Kaal) wrote:
>In article <9Kr+6JAV...@nthwd.demon.co.uk>, "B.MacDonald" <bu...@nthwd.demon.co.uk>
> <5eata2$j...@sun001.spd.dsccc.com> wrote:
>at that baud rate you will have maximum 9216 interrupts per second and with
>8250 UART you have to get the data out of the data register before the next
>one is received - if you cant do that you will have overrun error. With 16550
>you have 16-byte data queue which gives you 16 times more time to get to the
>first byte and after you have started pulling data off the queue more bytes
>can arrive so you may actually get something like 20 bytes per interrupt. This
>is what helps you to avoid overrun errors. Now, even with FIFOs you may still
>have problems depending on what you have to do with the data - disk writes,
>network access and TSR-s may run significant amount of times with interrupts
>disabled causing interrupt latency long enough to give you overruns even on
>16-byte FIFOs.
IDE block mode may be a factor here; lager blocks, longer periods with
interrupts disabled, more latency, more risk of data overrun.
>a) use a fast enough machine to handle over 9000 interrupts per second
>b) handle your data transfers in polled mode in reasonable chunks, with
> interrupts disabled (that does not necessarily work under multitaskers).
Multitasking is the key issue here. If the only task that is running
is the one that is transferring data, then no problem; you can just
stare at the UART status register until data arrives, and yank it off
straight away - hence comfortable 9600 bps on 8-bit Z80 at 3.5MHz.
But if you want to run something else, it's a problem. Even if you
never have overruns, the impact on the performance of the other
application is higher as each byte has to be handled via a seperate
interrupt call.
Generally, transmission isn't the problem, and you can leave the UART
set up to flush every 16 bytes i.e. generate an interrupt only when
the buffer is full (assuming bulk rather than scanty data, i.e. file
transfer rather than interactive keystroke transmission). You have to
handle both expected and unexpected (e.g. Ctrl-Break) end-of-file
situations, else the buffer won't fill, won't generate an interrupt,
and won't flush.
The receive buffer can be set to mininise interrupt calls as far as
possible without overruns, say generating an interrupt when the 12th
to 14th byte arrives in the buffer. You should still look at this
buffer every now and then so that if no further data comes in to fill
the buffer up to the interrupt mark, you can still get all the data.
John Jerrim
On 16 Feb 1997 21:40:01 GMT, obi...@engrs.unl.edu (Marc Lombardo)
wrote:
|hi,
|
|i'm using a 386sx (20mhz!) with a 1989 AMI bios, a 8250 UART and a US Robotics
|14.4K V.32bis with V.42bis Sportster modem. I have my serial port rate set at
|19.2K, and connect at 14400/ARQ/V32/LAPM/V42BIS. I am using a dial-in modem
|telnet server and after connecting to my unix (AIX) account, I send a break
|and do a 'set session passall' at the telnet prompt, as recommended by the
|system for successful zmodem transferring. I also set the modem to &K3 to
|disable MNP5 compression since I download compressed files almost exclusively.
|
|I can only successfully download files using zmodem without errors when I
|unload the majority of my TSRs and even then only get a max transfer speed of
|about 1k/sec with compressed files. I get tons of serial port errors (data
|overruns) when EMM386 or Norton AntiVirus are loaded. I cannot get zmodem
|transfers to work at all in the QuickLink II/FAX program included with my USR
|modem.
|
|I cannot get transfer rates above about 500-600 bytes/sec in Procomm for
|windows.
|
|I often have problems with the vt100 instructions not working properly as
|well, causing my screen to be too garbled to use (especially when TSRs are
|loaded, notably again EMM386 & Norton AntiVirus TSR, among others).
|
|My questions are:
|
|Will upgrading to a 16550 UART increase my transfer speed
|in dos by a decent amount? (allowing perhaps the 1.7K/s shown in the USR
|manual for compressed files at 14.4k, serial port set at 38400 or 57.6K
|using v.42bis)
|
|will upgrading to a 16550 UART allow me to use my tsrs and still achieve
|the same, or just about the same transfer rates?
|
|will upgrading to a 16550 uart allow me to achieve fast transfer rates even
|when i'm in windows?
If you are being limited by TSRs and the like, then a 16550A will
almost certainly improve your overall performance. Price is low -
starting around $20 for a single port card. We've posted a number of
reviews of 16550 and newer UARTs on our web page at
http://www.comminfo.com/pages/reviews. (No, we don't sell any of the
cards)
I hope this helps...
John Jerrim
Computer Telecommunication Systems, Inc.
Diagnostic & Installation Products for Modems & Serial Ports
World Wide Web: http://www.comminfo.com
FTP: ftp://ftp.comminfo.com/comminfo.com
E-Mail: jje...@comminfo.com
Voice: 1-770-263-8623
FAX: 1-770-263-0124
John Navas
[POSTED TO comp.dcom.modems]
cqu...@iafrica.com (Chris Quirke) wrote:
>IDE block mode may be a factor here; lager blocks, longer periods with
>interrupts disabled, more latency, more risk of data overrun.
Only with a brain-damaged BIOS/block driver. A good BIOS/block driver
allows interrupts to be service during a block transfer.
>Multitasking is the key issue here. If the only task that is running
>is the one that is transferring data, then no problem; you can just
>stare at the UART status register until data arrives, and yank it off
>straight away - hence comfortable 9600 bps on 8-bit Z80 at 3.5MHz.
No, interrupt latency is the key issue here. With a good multitasker
(e.g., DESQview), even an 8088 can multitask with interrupt-driven serial
comm, and a 286 can handle respectable modem speeds.
>Generally, transmission isn't the problem, and you can leave the UART
>set up to flush every 16 bytes i.e. generate an interrupt only when
>the buffer is full (assuming bulk rather than scanty data, i.e. file
>transfer rather than interactive keystroke transmission). You have to
>handle both expected and unexpected (e.g. Ctrl-Break) end-of-file
>situations, else the buffer won't fill, won't generate an interrupt,
>and won't flush.
The 16550 has logic to generate interrupts even when the FIFO does not
fill by timing out between characters.
>The receive buffer can be set to mininise interrupt calls as far as
>possible without overruns, say generating an interrupt when the 12th
>to 14th byte arrives in the buffer. You should still look at this
>buffer every now and then so that if no further data comes in to fill
>the buffer up to the interrupt mark, you can still get all the data.
See above.