From: jochen@busybit.mrz.sub.org (Jochen Fahrner)
Newsgroups: comp.unix.sysv386
Subject: Loosing incoming serial characters [summary]
Date: 5 Sep 92 12:56:19 GMT
Organization: Busybit's Software Labor, D-8068 Pfaffenhofen
X-Md4-Signature: 2df955ff714bdbd4a0b5884042ad66ae

Some weeks ago I wrote about problems, loosing incoming characters on
my dumb serial port. I got many replies from people with similar
problems, so I think this should be in the FAQ, even if it is not
frequently asked, because most people don't realize this problem.

So I will describe the problem in the way of an FAQ.

Question:
	My system looses incoming serial characters at speeds >2400bps
	even with fas and 16550 chips.
	I have SCSI-disks with busmaster dma hostadapter (like adaptec 1542)
or
	With uucp and V32bis connections I get 1300cps on outbound
	traffic, but only 800cps on inbound traffic.
	I have SCSI-disks with busmaster dma hostadapter (like adaptec 1542)

or
	My floppy is slow and sometimes I get floppy I/O-errors when
	there is activity on the hard disk.
	I have SCSI-disks with busmaster dma hostadapter (like adaptec 1542)

Answer:
The PC-Design is not very good for multitasking operating system like
unix or OS/2. There are at least 2 dumb periphery devices which needs
fast response by the cpu or the dma-chip: the floppy controller and
the dumb serial ports. These devices have no own intelligence and want
to get every byte in the right moment over the bus. In single tasking
environments like MS-DOS this is not a problem, there is no other
traffic on the bus when doing such things. In multitasking operating
systems this is also no problem, if the cpu is interruptable with the
desired speed and has control over the bus.

But there comes a problem with busmaster cards. These intelligent
cards can use the bus without cpu intervention. The cpu only says:
"read sector 4711 from disk 0 to memory location 0815". Thats all. The
busmaster adapter does the rest alone in a very fast way.

This has one big advantage: The cpu can do something else in the
meantime.

But: what happens, if the cpu wants to use the bus while the adapter
is transfering data to memory ? The cpu has to wait until the bus is
free. To avoid such conflicts, when the cpu has to serve some dumb
periphery, the busmaster adapters are configurable how long they can
use the bus and how long they should leave it free. These parameters
are called buson- and busoff-time. If the buson time is longer than 5
usec., you will get problems with your floppy drive.

This is the theory.
But here comes the practice:
The timings for busmaster dma was never exactly specified by ibm for
the isa-bus. So every mainboard manufacturer and every adapter
manufacturer implements a little variant of busmaster timing. If you
have luck, you will have a mainboard/adapter combination which works
without problems. But often you will have a combination which will not
work as described, the adapter does not leave the bus free at the
specified times.

Often you will not notice, that you have such trouble. The only time
critical devices are the floppy controller and the dumb com-ports.
The driver for the floppy controller will do some retries when there
are erorrs reading or writing the floppy disk. So you will only
mention slow floppy accesses.

The driver for the serial ports will have no chance to do a retry, but
mostly you will use some sort of file transfer protocol with the
serial device, like uucp-g or kermit, which will do its own retries
with communication failures. Again, you will notice only slow
throughput when receiving data. Sending data is not a problem, because
it is not time critical. You will not loose characters if the cpu can
not access the bus.

Question:
How can I determine, if I have problems with my busmaster hostadapter?

Answer:
1) If you have a high-speed modem:
   Configure it right, so that flow control works at 2400bps.
   Verify that flow control works, by doing some cpu-intensive
   work in the background.
   Login to a unix system, do something like "ls -lR" and watch the
   output. If scrolling stops and continues without loosing
   characters, your flow control works.
   Now try the same thing with 9600bps or 19200 bps. If you are
   loosing no characters with cpu-intensive tasks in the background,
   you are ok.
   Now try the same thing with 9600bps or 19200 bps with something   
   like "while true ; do cp /unix /foo; done" in the background.
   If you are now losing characters (the output columns of ls -lR are
   not aligned), you have problems with your host adapter.

2) If you have a streamer tape
   Boot from your boot-floppy, with root filesystem on floppy disk.
   Mount the harddisk and do some restore from tape to disk. If you
   get I/O errors with your floppy drive if the system accesses the
   floppy during restore (I don't know what the system does on floppy 
   disk during restore, but it does something on my system), you
   probably have problems with your hostadapter.

Caution: It is not enough to run the adaptec dma test at bios location
DC00:9. This only prooves, that the adaptec can access main memory
without problems. It does not test, if the cpu can acces the bus
within the specified buson-/busoff-times. With the above described
problems the hostadapter itself works very fine, problems arise when
the cpu wants to acces some dumb periphery devices during heavy(!)
disk-I/O.

Question:
How can I solve this problems ?

Answer:
Try setting the buson-time for your hostadapter to a low value like
5 usec. and setting the busoff-time to a high value like 9 usec.
If this does not help, you have no chance. You have to switch your
hostadapter or your mainboard.

I can recommend hostadapters which do memory-mapped I/O, like most of
the ethernet cards do. Memory mapped I/O has the same advantages like
busmaster-dma, but not the disadvantages,

If you have not simultaneous users logged in to your unix system, you
can also use adapters with programmed I/O (like adaptec 1522) with no
significant disadvanteges. I now use a 1522 and I am very happy with
this controller.

Jochen
-- 
Jochen Fahrner, D-8068 Pfaffenhofen, jochen@busybit.mrz.sub.org