Path: utzoo!utgpu!water!watmath!clyde!rutgers!mcnc!decvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!stl!stc!root44!njh
From: njh@root.co.uk (Nigel Horne)
Newsgroups: comp.mail.uucp
Subject: Re: 4800 > 9600 ?
Message-ID: <513@root44.co.uk>
Date: 12 Jan 88 13:42:18 GMT
References: <426@taux01.UUCP>
Reply-To: njh@root44.UUCP (Nigel Horne)
Organization: UniSoft Ltd., London, England
Lines: 51

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