amos@taux01.UUCP (Amos Shapir) (12/25/87)
Here's the situation: 2 systems running sysV.3, sitting on the same table, and connected by a direct line. There's no significant noise, and we can do cu and uucp at speeds up to 9600 baud. BUT: 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. No error messages are produced. Is this a common problem, or is it just us? Can anyone give us pointers for debugging this? It's ok to uucp at 4800 baud, but we occasionally have to use the same line for terminals, and switching baud rate is a nuisance. Thanks very much, -- Amos Shapir (My other cpu is a NS32532) National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 amos%taux01@nsc.com (used to be amos%nsta@nsc.com) 34 48 E / 32 10 N
rynes@mandrill.CWRU.Edu (Edward M. Rynes Esq.) (01/09/88)
In article <426@taux01.UUCP> amos%taux01@nsc.com (Amos Shapir) writes: >Here's the situation: 2 systems running sysV.3, sitting on the same table, >and connected by a direct line. There's no significant noise, and we can do >cu and uucp at speeds up to 9600 baud. BUT: 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. No >error messages are produced. > >Is this a common problem, or is it just us? Can anyone give us pointers >for debugging this? It's ok to uucp at 4800 baud, but we occasionally have >to use the same line for terminals, and switching baud rate is a nuisance. > > Thanks very much, >-- > Amos Shapir (My other cpu is a NS32532) >National Semiconductor (Israel) >6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 >amos%taux01@nsc.com (used to be amos%nsta@nsc.com) 34 48 E / 32 10 N We have the same problem connecting a Vax to a Data General over a serial line. After much confusion and too many hours of debuging I came to the conclusion that one or both machines could not keep up with the conversation at 9600 baud and some of the data was lost. There does not seem to be any flow control between the two systems. The master sends a packet then waits for a reply from the slave. (usualy about 10 seconds) if no reply is received it resends the packet. The first few packets seem to go OK but after that buffers start to fill and eventualy a packet will get lost. A lost packet will cause the slave to not respond causing the master to wait. The wait allows the buffers on the slave to empty out allowing the next few packets to get through. At 4800 baud both systems seem to keep up with the flow of data thus no lost packets and no waiting. This may or may not be the problem you are having but the results are the same. Good luck. ______________________________________________________________________________ Edward Rynes Unix Engineer | "Give me what I want, and all I A. R. Jennings Computing Center | Can think about is losing it. Case Western Reserve University | I'm losing it!" K.H. Cleveland, Ohio 44106 | (216) 368-2982 rynes@mandrill.CWRU.Edu | {cbosgd|decvax|sun}!mandrill!rynes ______________________________________________________________________________
john@uw-nsr.UUCP (John Sambrook) (01/11/88)
In article <2337@mandrill.CWRU.Edu> rynes@mandrill.CWRU.Edu (Edward M. Rynes Esq.) writes: > We have the same problem connecting a Vax to a Data General over a >serial line. After much confusion and too many hours of debuging I >came to the conclusion that one or both machines could not keep up >with the conversation at 9600 baud and some of the data was lost. >There does not seem to be any flow control between the two systems. >The master sends a packet then waits for a reply from the slave. >(usualy about 10 seconds) if no reply is received it resends the >packet. The first few packets seem to go OK but after that buffers >start to fill and eventualy a packet will get lost. A lost packet >will cause the slave to not respond causing the master to wait. The >wait allows the buffers on the slave to empty out allowing the next >few packets to get through. At 4800 baud both systems seem to keep >up with the flow of data thus no lost packets and no waiting. > > This may or may not be the problem you are having but the results >are the same. Good luck. I have also run into this problem on a Data General system. UUCP on Data General systems has always been a problem for our group and, I believe, for Data General as well. In the past the release notices for both MV/UX and DG/UX have included disclaimers to the effect of "The ability to handle UUCP at speeds greater than 4800 baud is a function of machine loading." Note that this is not a direct quote, but I think it is close. The good news is that DG/UX will be using HoneyDanBer UUCP starting with revision 4.00. At least that is what our local office claims. I can't say whether or not this will help throughput problems. I don't know if MV/UX will support it or not. I have also noticed that if I want to use Kermit to send a file to our DG MV/10000 I have to do so at 4800 baud or less. Any faster and I get lots and lots of packet errors. -- John Sambrook Internet: john@nsr.bioeng.washington.edu University of Washington RC-05 UUCP: uw-nsr!john Seattle, Washington 98195 Dial: (206) 548-4386
csg@pyramid.pyramid.com (Carl S. Gutekunst) (01/11/88)
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 <CR> 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. <csg>
njh@root.co.uk (Nigel Horne) (01/12/88)
In article <426@taux01.UUCP> amos%taux01@nsc.com (Amos Shapir) writes: >Here's the situation: 2 systems running sysV.3, sitting on the same table, >and connected by a direct line. There's no significant noise, and we can do >cu and uucp at speeds up to 9600 baud. BUT: 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. No >error messages are produced. > >Is this a common problem, or is it just us? Can anyone give us pointers >for debugging this? It's ok to uucp at 4800 baud, but we occasionally have >to use the same line for terminals, and switching baud rate is a nuisance. It's a very common problem, and it is unlikely that you can do a great deal about it as it stands. The problem lies in the *hardware*. What happens is this (greatly simplified - and not strictly accurate): 1) uucp sends out a packet of information (typically 64 bytes) 2) it waits for acknowledgement 3) if it gets the OK it then sends the next packet OR if the data is corrupted it sends the same packet OR if some data is lost is resends the same packet. It is the last of these which is occurring when you go from 4800 to 9600 baud. Your receive hardware just isn't capable of keeping up with 9600 - what ever your HW document/engineers are telling you. So when you splat a packet of bytes at the receive end the next character can sometimes be received *before* the previous character is read. Do you see? Simple ain't it, so some of the 64 (for example) are lost. Now, uucp expects this to happen from time to time so it does an alarm(2) before doing the read(fd, &buffer, 64) and it checks to see if all 64 were read, if not it says "hey - retry needed". The parameter to alarm is set fairly high - otherwise it'd always timeout at 110 baud (remember those days) for a different reason (this is left as an exercise for the reader). So between the end of the reads occurring and the alarm comming in, you have to wait a bit, which is what you're seeing. Remedies: 1) Kick your hardware people to implement some sort of input stack mechanism 2) Slow down the line to 4800 3) Implement hardware flow control (DTR/CTS - that kind of thing) 4) See if your software driver needs attention - it may be doing too many spl()'s, or not activating the interrupt mechanism very well. Clear? Good. -Nigel -- -- Nigel Horne, Director of Quality and Programmes, UniSoft Ltd. <njh@root.co.uk> G1ITH Fax: (01) 726 2750 Phone: +44 1 606 7799 Telex: 885995 UNISFT G BT Gold: CQQ173