Area Os2, Msg#1586, Sep-09-92 09:52PM From: Wilson Navarro To: All

Area Os2, Msg#1586, Sep-09-92 09:52PM From: Wilson Navarro To: All
Area Os2, Msg#1586, Sep-09-92 09:52PM
From: Wilson Navarro
To: All
Subject: 16550 under os2
I found this message on internet. I hope it helps someone understand com
ports under OS/2. ---------------------------------------------------------------------- Article 11617 (102 more) in comp.os.os2.misc: From:
[email protected]
(David Bolen)
Subject: COM performance hints with 16550 Date: Thu, 3 Sep 1992 20:18:53
GMT
Organization: Advanced Network & Services, Inc. - Elmsford, NY Lines: 325
Warning: This is pretty long, but there's a summary at the end.
just
want to see a brief statement now:
If you
If you have a 16550, have a serial device that keeps DSR high while
it is on (I think most modems do this by default, or are
configurable),
doesn't do hardware flow control, or doesn't mind getting up to 15
characters after dropping CTS and/or DSR, make sure you set
BUFFER=ON
when configuring your COM port with the MODE command. With default
settings, BUFFER=AUTO is really no different than BUFFER=DISABLED.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - I recently obtained a copy of the OS/2 physical device driver reference
and
was reading through the information about the async drivers
(COM/VCOM.SYS).
From the number of posts on the subject (some from myself), it seems that
a
number of people are confused about what the various MODE COM settings
mean,
and what sort of setup was the most efficient use of COM ports when a
16550
UART was present (which seems to be universally regarded as a good idea
to
have in order to gain good performance). I normally use OS/2 COM
programs
with the RTS=HS,BUFFER=AUTO settings (as is normally recommended on the
net
and in the FAQ) and wondered if I was fully exploiting the capabilities
of my
16550. In addition, I was still having problems with DOS environment
programs (notably kermit 3.11 that just dies a horrible death) and hoped
to
learn a bit about how that might be improved.
After reading a bit, and performing some experimentation, I've come up
with
the following information and conclusions that may help other people with
the
16550s. I don't place any guarantees on this information, other than
that it
is accurate to the best of my knowledge and seems to be backed up by my
experimental results. I hope it proves helpful, or at least helps to
explain
the relationship between some of the MODE parameters and the use of the
FIFO
buffers provided by the 16550.
(in the following, when I use the term 16550, the OS/2 drivers actually
require an NS-16550A or compatible chip, and I believe the current level
chips as discussed previously in the OS/2 groups are 16550AFN or
16550AF)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - Introduction:
-----------The 16550 provides for a 16-character receive hardware buffer that can be
set
to generate an interrupt every 1, 4, 8 or 14 characters. It can also
hold up
to 16 characters in a transmit buffer, generating an interrupt only when
that
buffer is empty. In other words, in its most efficient mode, the 16550
can
handle transmission and receipt of data in roughly 16-byte chunks, only
interrupting the CPU at the end of each chunk.
Note that even if you don't make use of the extended buffering from the
point
of view of interrupt handling, but still receive an interrupt for every
character received or transmitted, the 16550 buffer can be helpful, as it
can
buffer received characters if the COM handler misses an interrupt,
thereby
preventing receive overruns.
The OS/2 COM driver can fully exploit these capabilities of the 16550
depending on how it is configured. Here's the rub though - if you take
the
default COM settings, and even if you use MODE to set the BUFFER
parameter to
AUTO, the COM driver is only partially using the capabilities of the
UART. In
other words, the settings that are normally posted to these groups, and
are
in the FAQ are not the most efficient settings. In fact, from what I can
tell, a BUFFER value of AUTO is no better than DISABLED with the other
defaults for the modem signaling values.
COM Driver Settings (MODE):
-------------------------The extended hardware buffering mode of the async driver can be
controlled
via the BUFFER parameter of the MODE command. It can take on three
values:
ON
OFF
AUTO
transmit/receive
Set transmit/receive triggers to fully exploit buffering.
(16-character transmit/receive queues for 16550).
Set transmit/receive triggers to a single character.
"Automatic Protocol Override". Adjust the
triggers according to handshaking protocols in effect.
The "handshaking protocols" for AUTO mode use the following signals:
RTS
DTR
CTS
DCD
DSR
=
=
=
=
=
Request To Send
Data Terminal Ready
Clear To Send
Data Carrier Detect
Data Set Ready
( Signals FROM OS/2 COM Driver )
( Signals TO OS/2 COM Driver )
and refer to the following:
* Input Sensitivity using DSR
- MODE option IDSR, default ON
- If this setting is ON, then the driver will only accept data
from
the device while the DSR line is active.
* Output Handshaking using CTS, DSR, DCD
- MODE options OCTS, ODSR, default is both ON
- No MODE option for DCD - MODE always sets it OFF
- This setting controls whether CTS, DSR or DCD are used to
control
the flow of data to the modem. If any of these settings are
ON,
the driver stops giving data to the transmit hardware as soon
as
the corresponding control signal drops.
* RTS Control Mode
- MODE option RTS, default is ON. Can be one of the following:
+ Enabled
[MODE=ON]
+ Disabled
[MODE=OFF]
+ Input Handshaking (RTS drops on input queue full)
[MODE=HS]
+ Toggling on Transmit (RTS drops unless transmitting)
[MODE=TOG]
- This setting controls how the RTS signal is controlled by the
driver. If ON, DTR is used to signal when the COM port is
active, while if HS, DTR is used to control the flow of data
from the modem.
* DTR Control Mode
- MODE option DTR, default is ON. Can be one of the following:
+ Enabled
[MODE=ON]
+ Disabled
[MODE=OFF]
+ Input Handshaking (DTR drops on input queue full)
[MODE=HS]
- This setting controls how the DTR signal is used to control
the flow of data.
- This setting controls how the RTS signal is controlled by the
driver. If ON, DTR is used to signal when the COM port is
active, while if HS, DTR is used to control the flow of data
from the modem.
A typical default configuration for the COM port is (ignoring some of the
MODE parameters not relevant to this post):
IDSR = ON
OCTS = ON
RTS = ON
ODSR
= ON
DTR
= ON
BUFFER = AUTO
And most suggestions for configuring the COM port for better control
explicitly set RTS=HS, and BUFFER=AUTO, so I expect that many people are
running with the above settings, except with RTS=HS, allowing full
hardware
flow control (RTS/CTS) to the modem.
Setting Interaction:
------------------For the purposes of this post (getting the most performance out of the
16550), the only settings that are really important from the above
discussion
are the "Extended Hardware Buffering" (BUFFER), "Input Sensitivity using
DSR"
(IDSR), and "Output Handshaking using CTS, DSR, DCD" (OCTS,ODSR).
Here's the basic problem. In order to accomplish the latter two settings
in
their default modes, the AUTO buffering mode basically stops using the
FIFO
buffers. In particular, the following adjustments are "automatically"
made:
* If IDSR is enabled, then the COM driver is set up to respond
to a lowering of the DSR signal within one character time. To
ensure
this, the driver adjusts the receive trigger to be a single
character.
In other words, it lets the 16550 generate an interrupt per
character.
The full 16-character receive buffer is still available to prevent
receive overruns, and the transmit trigger is not adjusted.
* If either OCTS, ODSR (or ODCD - only changeable from a program) are
enabled, then the device driver will respond to a lowering of the
appropriate signal within a single character time. To do this, the
transmit trigger is lowered to a single character - the 16550 is set
to generate a transmit interrupt for each character, although the
receive trigger is not adjusted.
The reason both of these automatic adjustments are made is to take the
safe
course, and assume that anything using those signals has been designed to
assume that the signals take action within a single character time. For
example, without fixing the transmit trigger, the modem could lower the
CTS
signal, but the 16550 might continue transmitting up to 15 characters
that
might still be in the FIFO transmit queue.
Of course, the problem is that with the default settings, both of these
rules
come into effect, and the driver ends up getting an interrupt per
character
for both transmitting and receiving characters. In other words, you end
up
using the 16550 just like any lower UART, with the single advantage that
the
receive FIFO buffer on the chip helps avoid receive overruns.
Improving Settings
-----------------In order to make more effective use of the 16550, you can do one of three
things:
* Explicitly set the extended buffering on (MODE BUFFER=ON).
* Disable IDSR sensitivity (MODE IDSR=OFF)
* Disable any output flow control (MODE OCTS=OFF,ODSR=OFF)
Of the three, I generally prefer the former, but you may have reasons to
do
one of the latter two. By explicitly setting the buffering on, you will
override the rules above that adjust the receive and transmit triggers.
What
this means is that you may receive extraneous data if DSR is actually
being
used to signal input and that if the modem asks the driver to stop
sending
data (CTS), it may still receive up to 15 more characters.
I don't think either of these problems should hit most people using
modems
today. I believe most modems hold DSR high while they are on (or at
least
are configurable to do this), and most modems that handle hardware flow
control (RTS/CTS) drop CTS before they are absolutely out of room. For
example, the USR Courier v.32bis modem I have has a transmit buffer of
1.5K
(3.25K for error control connections) and drops CTS when the buffer is
90%
full (plenty of room for 15 extra characters). But of course, for a
specific
case the second or third choice can be made, which will make better use
of
the 16550 than the default settings, but not the best.
Some experiments
---------------Just to see if any of the stuff I was learning seemed to apply, I ran
some
quick tests. Nothing extremely scientific - just a couple of quick file
transfers.
Using a SLIP connection (TCP/IP over a serial line), with USR v.32bis
modems
on either end, I transferred a reasonably sized (115K or so) file down
from a
workstation. My COM port was set at 38.4K. The transfer was from the
workstation back to my machine so I was mostly testing the receive
characteristics although the program used (FTP) does transmit data during
the
transfer.
I tested using both the normal COM port settings (plus RTS=HS), and then
with
BUFFER=ON rather than AUTO. Also, I first ran the transfers without
anything
else occurring on the system, and then re-ran the same transfers with a
PM
monitor (one of the ones from ftp-os2 - pmload11.zoo). The results were
interesting:
FTP Transfer Time (binary mode, size = 114688 bytes)
MONITOR
BUFFER
Time (s)
Rate (cps)
Load (%)
--------------------------------------------------------------------No
Auto
41
2797
N/A
No
On
41
2797
N/A
Yes
Yes
Auto
On
53
41
2164
2797
98-100
82-86
When nothing else was running, BUFFER didn't really make much of a
difference. I guess this just meant that my machine itself was fast
enough to
keep up with an interrupt a character in general. I presume though
(given
the next set of results) that the load on the system in the On mode was
much
less.
When something was running (even the load program, as a PM program, takes
up
CPU time and interferes with running applications - I had it iconized, so
it
had to update the icon each second), things were very different. In Auto
mode, I got a much worse transfer time, and my system load was pretty
much
pegged at 100%. In On mode, I got as good a transfer time as when
nothing
else was running, but at a much smaller load on the machine.
So I think this is pretty strong evidence that using BUFFER=ON is very
different than BUFFER=AUTO when the other signaling settings are using
their
default values.
Virtual COM Driver (DOS Boxes)
-----------------------------After reading about VCOM (of which little is written), I don't see a
magic
pill for DOS box users, other than that a BUFFER=ON setting should help
lower
the CPU load and make it easier to keep the virtual interrupt rate up in
the
DOS environment.
There was one discovery I did make however, that may help some people
out.
VCOM supports two modes of accessing the COM ports - either through BIOS
calls or via virtual I/O ports. The virtual I/O ports only emulate the
lower
end INS8250 UART, and as others have noted, the virtual interrupt rate is
limited to around 1000Hz or so.
Since I figured it had something to do with the virtual I/O
was
causing the most problem with kermit, I reset kermit to use
method for accessing the COM port. Although access through
technically limited to 9600 baud maximum, I was able to run
without a
ports that
BIOS1 as its
the BIOS is
kermit
failure, including file downloads. When letting kermit use the virtual
I/O
port, I'd generate traps at rates even as low as 2400 baud.
I think this behavior arises from the fact that when the application is
controlling the hardware directly, it is issuing a lot more I/O requests
to
the virtual I/O port that must be handled by VCOM. With the BIOS
interface,
the application basically asks BIOS for a character, and gets them back
one
at a time. Since VCOM goes off to COM to get the character, all of the
hardware flow control and buffering used by COM is available to VCOM, and
the
DOS application doesn't have to concern itself with anything.
So - if someone else is trying to run a COM program in a DOS box and it
can
use BIOS to access the COM port rather than trying to run the hardware
itself
you may be able to get it working reasonably. At the very least, it gave
me
a way to test the DOS version of kermit some of my users use from home at
a
reasonable speed (although not as high as I would like) from within a DOS
box.
Summary
------An important aspect of the support for 16550 UARTs within the OS/2 2.0
COM
driver is the interaction between various modem control handshaking
settings
and the automatic control of extended buffering. In particular, several
of
the default COM port settings (IDSR=ON,OCTS=ON,ODSR=ON) when automatic
control (BUFFER=AUTO) is enabled force the driver not to use the enhanced
buffering of the 16550, and instead generate interrupts for each
character
transmitted or received. This can decrease performance and definitely
places
a heavier load on the machine.
The easiest way to solve this is to use a setting of BUFFER=ON rather
than
BUFFER=AUTO, as long as it won't cause problems overrunning your modem or
receiving extraneous information (see "Improving Settings" above). I
don't
think many users will encounter a problem if they make these changes.
From
my experiments, switching to BUFFER=ON can decrease the load on a 16MHz
386
by at least 15%, while allowing the same transfer rate on a busier
system.
For the DOS Box, one hint to users trying to get reasonable performance
out
of DOS COM applications - BUFFER=ON may also help this situation, but if
you
can live with 9600 baud, and your application supports using the BIOS
interface to the COM port, try using that mode. You may be to run the
application successfully at higher data rates through the emulated BIOS
interface than if the application tries to use the emulated COM hardware
directly.
I hope someone else finds this information useful - I know it's helped me
to
get a better handle on how OS/2 manages the COM port, and how various
settings affect its use of the capabilities of my 16550 UARTs.
--- David
-/-----------------------------------------------------------------------\
\
David Bolen
\ Internet: [email protected]
/
|
Advanced Network & Services, Inc.
\
Phone: (914) 789-5327
|
/ 100 Clearbrook Road, Elmsford, NY 10523 \
Fax: (914) 789-5310
\
\----------------------------------------------------------------------/
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement