> I finally found some time to try UUCP again. The good news
> is that transferrates are pretty good:
> 
> uucico sun4nl - (1995-12-08 02:41:48.33 11637) Calling system sun4nl (port mdm02)
> uucico sun4nl - (1995-12-08 02:42:16.36 11637) Login successful
> uucico sun4nl - (1995-12-08 02:42:16.81 11637) Handshake successful (protocol 'i' sending packet/window 1024/16 receiving 1024/16)
> uucico sun4nl waldi (1995-12-08 02:42:17.85 11637) Receiving /var/spool/uucppublic/incoming/ls-lR.gz
> uucico sun4nl - (1995-12-08 02:45:09.26 11637) Protocol 'i' packets: sent 5, resent 0, received 354
> uucico sun4nl - (1995-12-08 02:45:09.27 11637) Errors: header 6, checksum 6, order 0, remote rejects 1
> uucico sun4nl - (1995-12-08 02:45:09.31 11637) Call complete (174 seconds 356692 bytes 2049 bps)
> 
> The link speed was 19K2, DTE/DCE speed 38K4. There was a ring-overflow
> notice in /var/log/messages, so I guess we might increase the buffer a
> little more (Leo?).
If there is only a single overflow, I think we can live with it. At least we
should have a look if it still happens when the scsi-driver is modified to
run at spl0 most of the time. I plan to look at Paul Kranenburg's patches
for the sun. He modified the serial driver to allocate the ring-buffers
when needed. Currently, they are pre-allocated in bss. This wasn't that
bad with small buffers, but when we continue to increase the ring-buffer,
it becomes a waste of memory.
> 
> The bad news is that three out of four times uucico crashes the
> system when it is finished (before or while closing the port).
> Anyone else seen this? Fixed it?
Well, I recall Thomas having problems with mgetty on mdm02. His Falcon
was sometimes hanging after mgetty closed the port. It looks like the
same problem and hence it should be in the zs-driver. I tried to reproduce
it a few months ago but that didn't work. I guess we should take another
look...

Leo.