[net.bugs.uucp] timeouts in uucp

root@motel6.UUCP (The Man) (03/04/86)

I have a uucp connection from a pdp11 running 2.9BSD and a vax 785 running
ultrix version 1.  When sending data from the vax to the pdp, about every
4000 characters or so, it times out - pauses for 20 seconds - and then
restarts.

If disk activity is occuring, it times out much more frequently.  But,
with no disk activity, it still times out.  It doesn't care if
the cpu is loaded, running a cpu bound job that soaks up all the
spare cpu cycles does not affect it.  It does care if uucico is niced,
with no other active process in the system, if uucico is niced, it
times out less frequently.  But, if a disk bound job is running, it
still times out, as freqently as if disk activity were occuring and
uucico was not niced.

The disk system is as cheap as I could get - a Q-bus to scsi adaptor and
5.25" disks on an adaptec board.  I/O bandwidth is about 2.5Mbits/second.
DMA is done in the worst possible style, "bus-hog" where the controller
takes over the bus for the entire transfer.  But, at 2.5Mbits per second,
(.3125 Mbytes/sec) a 512 byte transfer should only take 0.0016384 seconds
and 1200 baud means each character takes 0.00833333 seconds to receive.  So,
this should not be a problem.  Moreover, I put some code in the serial
driver to see if characters were being ignored and found that they were not,
in fact character interrupts are being serviced in a timely fashion.

I put some hooks into the kernel to watch terminal input because
I thought that the input clist might be overflowing.  This is not
the case.

I wrote a new line discipline that only wakes up the reading process when
it's read can be satisfied.  This eliminates the context switch overhead of
RAW mode input.  This is not a complete solution, it reduced the time-outs
to the current level, but I can't eliminate them entirely.  It also reduced
the cpu usage of uucico to a reasonable level - cpu time is now about
10% of the actual time.

I am baffled by this one completely.  An unloaded cpu should be
able to sustain at least 1200 baud communication indefinitly.

Keith Packard
...!tektronix!reed!motel6!keith
(503) 771-1305