sandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz) (02/07/89)
I have run across another problem using flow control with Telebit-Plus
modem! This one seems to be in uucico. If I have a user log into the system,
using a standard shell, and I do a "stty" on the port, ctsflow is enabled
< I call it out in my gettydefs file >. HOWEVER, when I do a "stty" command
while a uucp transfer is in progress at 19.2K baud, I get returned
a -ctsflow !!!!!! It seems that SCO must be doing an ioctl call in uucico
which removes the preset terminal parameters. Actually, they should since
uucp should be running at 8N1. But CTSFLOW SHOULD NOT BE REMOVED if enabled!
I have sent two requests already to SCO for their CTS/RST Flow control
patches; however, I have not heard a single word from them. I am wondering
if one of the patches is to uucico to allow the preset getty/gettydef
parameters to be used without changes in uucico.
<sandy>
--
Sanford <sandy> Zelkovitz XBBS 714-898-8634
UUCP: ....att!hermix!alphacm!sandy ....trwrb!ucla-an!alphacm!sandy
....uunet!turnkey!alphacm!sandy ....ucbvax!ucivax!icnvax!alphacm!sandy
DATA: 714-898-8634 VOICE: 714-894-7898rac@sherpa.UUCP (Roger A. Cornelius) (02/09/89)
From article <5609@turnkey.TCC.COM>, by sandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz): > I have run across another problem using flow control with Telebit-Plus > modem! This one seems to be in uucico. If I have a user log into the system, > using a standard shell, and I do a "stty" on the port, ctsflow is enabled > < I call it out in my gettydefs file >. HOWEVER, when I do a "stty" command > while a uucp transfer is in progress at 19.2K baud, I get returned > a -ctsflow !!!!!! It seems that SCO must be doing an ioctl call in uucico > which removes the preset terminal parameters. Actually, they should since > uucp should be running at 8N1. But CTSFLOW SHOULD NOT BE REMOVED if enabled! I've got the same problem on the 286 version (2.2.3). If I dial out on the line (using cu or uucp with SCO's dialTBIT), and then do a stty -a <tty?? it shows both -ctsflow and -rtsflow. Dial-ins do show ctsflow enabled when I have only CTSFLOW enabled in gettydefs. But if I put both CTSFLOW and RTSFLOW in gettydefs and then dial in on the line, the port locks up as soon as I enter the password, and I can't get past that point. It appears that RTSFLOW is not supported. > I have sent two requests already to SCO for their CTS/RST Flow control > patches; however, I have not heard a single word from them. I am wondering > if one of the patches is to uucico to allow the preset getty/gettydef > parameters to be used without changes in uucico. I spoke with tech support Monday (02/06) and they put me on the list to receive the fix when engineering finishes with it. Roger rac@sherpa uunet!sherpa!rac
bill@ssbn.WLK.COM (Bill Kennedy) (02/10/89)
I will not repeat Sandy's or Roger's remarks about the ctsflow and
-ctsflow phenomenon. In particular, however, they're complaining
about their stty getting unwound by uucico and throughput problems
as a result. I emailed Sandy a suggestion and he confirmed similar
results.
My systems are a '386 AT clone with AT&T 386 UNIX Vr3.1 and a '286
AT clone with Microport V/AT 2.4. Each is Trailbalzer equipped,
neither does a very good job with CTS flow control. I did have one
of the TB's on a smart card that speaks CTS flow control but had
terrible performance at 1200bps.
I am routinely and reliably performing uucp transfers with the interface
locked at 19,200bps, auto-baud on the analog side and *NO* flow control.
I have a ghastly hack in /etc/profile for login users < 9600bps that does
set XON/XOFF handshaking, it gets reset with the DTR transition that
concludes the session. I was very skeptical about this set up until one
uucp neighbor (a Trailblazer) complained about crummy transfer rates
and another (1200bps only) did too.
I believe that the phenomenon Sandy and Roger are complaining about is the
uucico setting raw mode, thus defeating ctsflow. I have found, and Sandy
confirms, that the uucico's pace each other at any modem speed and that
throughput actually _increases_ when you remove all flow control. That is,
of course, not true for a login user running vi at 1200bps :-) but the
XON/XOFF flow control handles that one. I know you're talking about Xenix
here, and I wouldn't have brought it up had Sandy not said it worked. My
observation is based on ~20hrs off hook a week with no complaints.
--
Bill Kennedy usenet {killer,att,cs.utexas.edu,sun!daver}!ssbn!bill
internet bill@ssbn.WLK.COM