Using 14400/28000 modems under IRIX
: I didn't see anywhere in my systems how to set up a gettydefs files :(and maybe others) to connect to 14400/V42bis. : Furthermore, when i select dx_19200 mode, I receive : CONNECT 19200 : This must be a script output cause my modem can't handle that speed : eh ! : Is there a Dialers/inittab/gettydefs family that will allow me to :do so somewhere ?
There is a misunderstanding expressed here about exactly what '14400' means.
Modems are rated by the number of bits per second (bps) *total* that get transmitted between two modems. The bits being referred to are not the source data stream, but are instead whatever the modems care to send, as long as the modem at the other ends knows how to decode what was actually sent in order to reproduce the source data stream.
Modern modems transfer between themselves using 'frames' of bits, each frame encoding some of the source bit stream. Each frame has some associated frame-type information, sequencing information, and sufficient redundant data bits that the modem at the other end can detect and possibly correct bits that were corrupted in transmission. These overhead bits generally cut a bit into the bandwidth, reducing the capacity available to transmit source data bits.
Serial ports are rated on the number of bits per second transmitted through them, not on the number of characters per second transmitted through them. An asychronous serial port that operates at (say) 19200 bits per second can only transfer roughly 1920 eight-bit characters per second, as each asynchronous character requires a 'start bit' and a 'stop bit', for a total of 10 bits per eight-bit character. If you were to somehow manage to set your asynch serial port to 14400 bits per second, the port would only be able to handle 1440 characters per second.
Modern modems do not, though, use asychronous transfers between themselves: they use synchronous transfers in which the start and stop bit are not needed. A modem which was able to transmit 14400 "usable" bits per second [i.e., after overhead] could transfer 14400/8 = 1800 characters per second, which would require an 18000 bps asynchronous serial port to keep up with. If you were only transferring 1440 characters per second because you had managed to set your asynch serial port to 14400, then only 11520 "usable" bits per second would be needed to carry that capacity, and so you would be underutilizing the modem by the difference between the 11520 usable bits required and the up-to- 14400 bits per second that the modem can handle. If the frame overhead per second works out to less than 2880 (which is 20% of the channel capacity) then you would be underutilizing the modem to set your serial port to 14400 bps.
There is another factor. As it is enough for the transmitted data stream to be -decodable- back into the source data stream, any consistant representation for a block of data can be used. In particular, one can transmit a compressed version of the data, and decompress it at the other end. When transmitting text, repeated characters [such as leading spaces due to paragraph indentation] can be compressed down a flag byte, a count, and a single copy of the character: three characters in all being used to represent what might be a 10-column indentation. 24 bits get transmitted instead of 80, and the modem at the other end automatically undoes this RLE compression. If we are transmitting some relatively redundant data, such as an ASCII version of a Christmas tree, we could well end up averaging 80 transmitted bits (10 characters) per line that would normally take 400 transmitted bits (50 characters) if not compressed. At 14400 transmitted bits per second, the modem thus might be able to handle transfering 180 such lines per second -- but on the other end, this would expand out to 9000 characters per second, which would require a 90000 bps asynchronous serial port to keep up with.
Different compression schemes can be used. 'V.42bis' is one possible compression scheme, and averages about 2:1 to 3:1 compression on English text. One might need to run one's port at roughly 38400 bits per second in order to keep up with the 14400 bits per second that the modem is physically transmitting. Just in case something -very- compressible comes along, it would be better to run one's port at 57600 or 115200 bits per second even, except that SGI does not support more than 38400 on most systems. [The Challenge/Onyx and PowerChallenge/ PowerOnyx now support a board called the ASO, "Audio/Serial Option", that has 6 serial ports, each operable at 115.2K bits/second. At present, no other SGI systems support over 38400 bits/second, due to hardware limitations. The 4D/20 supports only 19200, as did the earlier versions of the CDSIO 6 port VME serial card.]
How does one match up one's port rate to the rate the modem is transmitting right *now* ? Answer: one doesn't! Instead, one should set one's serial port to the highest rate that it will support reliably, and instruct one's modem to also communicate at that rate *to the serial port*. No matter what carrier frequency or instantaneous transfer rate is in effect, the modem and serial port should "lock" the communications rate. [This is to be done at the modem by setting it up carefully.] If the serial port rate is higher than the instantaneous communications rate, the modem tells the computer to slow down. If the instantaneous communications rate is higher than the serial port rate (because the compression was quite good for a little time) the computer tells the modem to slow down.
The process of the two devices telling each other to slow down or speed up at need, is known as 'flow control'. There are two kinds of flow control in common use: "software flow control" and "hardware flow control".
Software flow control reserves two otherwise-valid data characters (^Q and ^S) as 'go-ahead' and 'stop for now' signals. If the modem needs to tell the computer to slow down, it sends a ^S, which the computer will notice and will respond to by stopping sending data until the modem figures it has enough room and sends a ^Q. The big problem with software flow control is that it is not possible for the modem and computer to figure out when the ^Q or ^S were really supposed to be there as part of the data stream (for example as part of a binary file), which makes it impossible to get these two characters to the other end. The common transfer protocols 'x-modem' and 'y-modem' cannot be used where software flow control is in use: both protocols will definitely send ^Q and ^S as part of the protocol overhead even if the file itself does not have these characters. 'zmodem' and 'kermit' know about these sorts of problems and can be used with software flow control. In order to take advantage of software flow control, you can use any serial port name, but you must have stty ixon in effect (possibly by having included the appropriate flag in the /etc/gettydef entry for the device.)
Hardware flow control does not reserve any data characters as signals. Instead, hardware flow control requires additional wires in the cable, and manipulates the signals on those wires in order to signal whether or not additional data may be sent. Hardware flow control is much more reliable than software flow control -- but it does require cables that carry more than the minimum 3 wires that software flow control can get away with. In order to take advantage of hardware flow control, you must use a serial port name which begins with 'ttyf' followed by the number of the port. Hardware flow control is considered to be a superset of 'modem control' (ttym*), so you must also have 'carrier detect' wired up in order to use hardware flow control on an SGI. This has some subtle implications for dialling out -- implications that 'cu' will take care of for you, but which you need to know more about if you wish to dial out with kermit.
In summary: run your serial port as fast as you can (38400 except on old SGI machines; 115.2K with the ASO), and configure your modem to always use that same rate when talking to the serial port. Use hardware flow control if you can. The rest of the details will be taken care of automatically by the buffers on the modem.
Last update June 28, 1995, 18:30 CDT by Walter Roberson, [email protected]