Path: utzoo!mnetor!uunet!husc6!sri-unix!ctnews!pyramid!csg From: csg@pyramid.pyramid.com (Carl S. Gutekunst) Newsgroups: comp.mail.uucp Subject: Re: 4800 > 9600 ? Message-ID: <12971@pyramid.pyramid.com> Date: 11 Jan 88 08:24:23 GMT References: <426@taux01.UUCP> Reply-To: csg@pyramid.UUCP (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 38 In article <426@taux01.UUCP> amos%taux01@nsc.com (Amos Shapir) writes: >... 2 systems running sysV.3, sitting on the same table, and connected by a >direct line.... while at up to 4800 baud transfer rates look consistent with >the baud rate, at 9600 baud uucp behaves strangely - it seems that after >passing each packet, it stops for about 10 seconds. Simple, and unfortunately common. The standard uucp 'g' protocol can send up to three packets of 70 bytes each without any acknowledgement. The receiving system must therefore be able to accept 210 bytes of input, without any flow control, and without losing any characters. In theory this should be easy, since the standard UNIX input buffer size is 256 bytes. However, the design of the UNIX kernel is such that it spends a tremendous amount of time with system interrupts disabled. If you are using a serial interface that has no hardware buffering, then the interface *must* be able to get an interrupt through to the system within one character time. If it cannot, the character goes into the bit bucket. The 10-second pause is the timeout while uucico waits for the characters that will never arrive. It then asks for retransmission, and life continues. The limit varies from system to system. On my PDP-11/73, I can get uucico to accept input beautifully at 9600 so long as absolutely nothing else is going on. If I so much as press on the console, or uucico needs to flush blocks to disk, I get the infamous 10-second pause. On other machines, you'll have different limits. A number of posters have observed a limit of 4800 on Data General machines. I have also noticed problems on systems using the Systek 8-channel multiplexor card, including the Sun 2 and 3, and Sequent Balance; this is probably the inability of the multiplexor to respond to it's *own* interrupts, not the responsiveness of the system CPU. The "solution" is to use a smart, buffered serial interface. Or redisign the kernel to not disable interrupts so much. Or get a much faster CPU. (Note that the Sun 3 does just fine on its A and B ports.) Or just don't try to run faster than it appears your system will tolerate.