Do I really need to BREAK to change baud rates?

[Ronald S H Khoo]

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)