rf@wu1.UUCP (03/26/84)
Eight bit data transfer is likely to upset some terminals and
some data transport networks. Unfortunately, the nearest to a
standard Ascii asynchronous protocol we have is seven-bit, even
parity, xon/xoff flow control (control-s/control-q). There are
numerous programs likely to be upset by the receipt of eight bit
data (csh and ingres to name two). Some older terminals much
prefer parity.
>>> FLAME ON <<<
I'm going to use the space to plead for cleaner communications
interface design. The hopeless lack of standardization in the
terminals and line interfaces used with Unix systems means that
any code we write to handle communications is device dependent.
I want a terminal handler which is flexible enough to be
customized to *any* protocol. If this means that we have to
devise a method of dynamically loading kernel code, so be it.
What are called "tty" ports are used for four things:
1. Local connections to keyboard terminals at speeds of 9600
bits per second or more.
2. Local connections to fast printers at speed of 9600 bps or
more.
3. Remote connections to keyboard terminals at speed of 110 to
9600 bps (since 9600 bps requires a dedicated line -- or
true half-duplex operation -- this speed is unusual).
4. Remote connections to computers at speeds of 300 to 56,000
bits per second.
Unix handles local connections reasonably well. Type 103 and
212 modems are handled passably in asynchronous answer mode,
though many 68,000 Unices do not properly recognize some RS-232
signals. Dialout modems are handled somewhat awkwardly, and
*no* synchronous or half-duplex modems are supported without
extensive hacks to the kernel. The reception of data at high
speeds is handled by the same code which handles keyboard input
-- an appalling waste of CPU capacity.
Unix is a product of the company which *invented* the modem.
Come on! Can't we do a little better?
One final flare: the term "baud" refers to state changes on a
transmission line -- *NOT* "bit rate". A 9600 bit per second
modem operates at 2400 baud.
decvax!philabs!wu1!rf Randolph Fritz
Western Union Telegraphrpw3@fortune.UUCP (03/29/84)
#R:wu1:-26700:fortune:11600078:000:1710
fortune!rpw3 Mar 28 20:04:00 1984
If you're going to be pedantic, at least get it right!
A "baud" is the reciprocal of the smallest signaling interval. For
equi-spaced signaling alphabets, the baud rate equals the symbol rate.
For binary signalling with no overhead, bits/sec equals baud.
True, a Bell 209 modem operates at 2400 baud ON THE TELEPHONE LINE SIDE,
where QAM modulation is employed and 4 bits/baud are achieved. But on the
digital (RS-232) side, WHICH IS THE ONLY SIDE USERS NORMALLY SEE, binary
signalling is used, wherein 9600 bits/sec = 9600 baud.
Moreover, on async ports (the vast majority of UNIX connections, no?), the
common use of the term "baud" is actually CORRECT, and using "bits" would
be WRONG! A Bell 212A, on the RS-232 side, handling async with one start
bit and one stop bit and 8 data bits, is 1200 BAUD, but only 960 BITS/sec.
Likewise, the hardwired connection I am using to type this message is
9600 BAUD (104.2 microsecond/symbol), but since I use async with 1 start
bit and one stop bit, I achieve but 7680 bits/second (if you count a char
as 8 data bits, and 6720 bits/sec if you call it 7 bits + parity).
No matter how you count it, though, it comes out to 960 characters/second.
By using synchronous transmission on a 1200 baud modem (which can be
done with either Bell 212A's or Vadic's), one can actually get 1200 BITS
per second, or 150 8-bit bytes/sec (instead of 120 bytes/sec). I have used
stat muxes over Vadic's in this mode, with 4 1200-baud (1S+8D+1S async)
(120 8-bit byte/sec) terminals sharing the line quite nicely.
Rob Warnock
UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065