Do I really need to BREAK to change baud rates?
Ronald S H Khoo
ronald at robobar.co.uk
Fri Dec 28 08:08:28 AEST 1990
kabra437 at pallas.UUCP (Ken Abrams) writes:
> There IS an alternative hardware solution. Replace the modem at the host
> with one that is buffered so you can set the Xenix baud rate at a fixed
> value and leave it there.
Genrally speaking, this is good advice. It's becoming more and more
important too, as the data compression in the modems renders the
relationship between the modem carrier speed and the DTE speed more fuzzy.
However, the caveat here is that you *absolutely* need hardware flow control
between the modem and the host, particularly at the higher speeds.
Using xon/xoff flow control just doesn't hack it because it interferes
with the user's use of it for paging, and anyway emacs switches it off.
Now, this presents a problem. Many intelligent serial ports just don't
support hardware flow control, and worse still SCO's own standard serial
driver's flow control logic is wrong, in that xon/xoff flow control and
cts/rts flow control interfere with each other(*). Worse still, if you
run any program that uses the v7 TIOCSETP calls, they *force off*
the ctsflow and rtsflow flags.
However, if you use an intelligent serial port with a driver that
flow controls properly, and can arrange not to run programs that
use the v7 compatibility ioctls, then the result is very good.
(I used to run a commercial BBS in the UK that does just that with
Hayes V series modems, and a Specialix serial adaptor. Actually,
for hysterical reasons, I only locked the speed interface when
error correction was active (and that's when hardware flow control
becomes nearly mandatory anyway) but I matched baud rates when
error correction wasn't active -- as you can guess, I made no
use of getty -- the modems were spoken to by a severely hacked
copy of the SCO dialer program -- so I could parse the CONNECT
message to determine what baud rate to speak at, and to determine
what kind of error correction/data compression protocols were active)
(*) It's easy to see where the interference goes wrong. Make a call
over a modem link where the modem carrier speed is lowish (say 1200
or 2400, but where the the DTE speed is 19200 or something. Now
make sure that ixon and ctsflow are set, then do something like
yes "the quick brown fox jumps over the lazy dog" to generate lots of
output. If you look at the modem lights, you will see that
CTS flow control works beautifully, and no characters would be lost.
Now type a ^S at the session, and output will stop, but when you
type ^Q to restart the output, CTS flow control no longer works
and you lose tons of characters. It looks like they've overeconomised
by just using one flag for both sorts of output flow control, when you
do really need two, as they are completely orthogonal. Specialix's
serial driver gets this right. I'd like to hear who else does.
--
ronald at robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
More information about the Comp.unix.xenix.sco
mailing list