sl@wimsey.bc.ca (Stuart Lynne) (04/27/91)
-- Stuart Lynne Computer Signal Corporation, Canada ...!van-bc!sl 604-937-7785 604-937-7718(fax) sl@wimsey.bc.ca
sl@wimsey.bc.ca (Stuart Lynne) (04/27/91)
I'm considering replacing my old 2400 bps modems with new 2400 bps with MNP5 and V.42bis modems for my low speed interactive users. The problem I have is that the Equinox card I have does not (easily) support hardware flow control. Is it easy to use make effective use of these modems by locking the interface at 4800 bps? The problem as I understand it is trying to use file transfer programs (uucp, [xyz]modem, kermit) to send compressed files. Is there any work around other than using hardware flow control? -- Stuart Lynne Computer Signal Corporation, Canada ...!van-bc!sl 604-937-7785 604-937-7718(fax) sl@wimsey.bc.ca
splee@pogo.gnu.ai.mit.edu (Seng-Poh Lee, Speedy) (04/28/91)
In article <1991Apr27.072711.6600@wimsey.bc.ca> sl@wimsey.bc.ca (Stuart Lynne) writes: >I'm considering replacing my old 2400 bps modems with new 2400 bps with MNP5 >and V.42bis modems for my low speed interactive users. > >The problem I have is that the Equinox card I have does not (easily) support >hardware flow control. Is it easy to use make effective use of these modems >by locking the interface at 4800 bps? > >The problem as I understand it is trying to use file transfer programs (uucp, >[xyz]modem, kermit) to send compressed files. Is there any work around other >than using hardware flow control? > This has been a problem with MNP modems, where you always want to run the DTE speed faster than the modem. However, this is hard to do without hardflow control. THe only hope you have is that whatever protocol you use requires an ack before the buffer in your MNP modem fills up. If your buffer is big enough, you can get away with x,ymodem, and kermit. However you have to run zmodem in a non-streaming mode i.i; requires ack. Also you have to make sure you disable the xon/xoff flow control as well. Try and get a modem which has at LEAST 4K of outgoing MNP buffer. And yes, you would lock your DTE rate to 4800 or higher. Hopefully the modems you buy will do speed buffering if a user calls in without MNP. THey should. -- Seng-Poh Lee splee@gnu.ai.mit.edu
tnixon@hayes.uucp (04/29/91)
In article <1991Apr27.072711.6600@wimsey.bc.ca>, sl@wimsey.bc.ca (Stuart Lynne) writes: > I'm considering replacing my old 2400 bps modems with new 2400 bps with MNP5 > and V.42bis modems for my low speed interactive users. > > The problem I have is that the Equinox card I have does not (easily) support > hardware flow control. Is it easy to use make effective use of these modems > by locking the interface at 4800 bps? Not really. You will DEFINITELY overrun the buffers in the modem that way when you're transmitting streams of text. You might get by without flow control if you were using a file transfer protocol whose frame size was smaller than the modem's buffer size; all of the protocols you mention, except YMODEM, can be made to work one way or another -- and yuou've have to put ZMODEM into single-frame window (stop and wait) mode [gag...]. > The problem as I understand it is trying to use file transfer programs (uucp, > [xyz]modem, kermit) to send compressed files. Is there any work around other > than using hardware flow control? Do you have access to the code so that you could modify the low-level XON/XOFF flow control and implement Transparent XON/XOFF? If so, you might want to use Hayes V-series Smartmodem 2400s (which have MNP5 and V.42bis) and use them in &K5 mode (Transparent XON/XOFF). It's really quite simple: In the transmitter, examine the transmitted data byte-by-byte. If the byte is a 0x10, 0x11, 0x13, 0x90, 0x91, or 0x93, XOR it with 0x21, prefix it with 0x10, and send it. The modem undoes the transparency, and the other end never knows you've done it. In the receive, examine the incoming data. If you get a 0x10 or 0x90, discard it; on the next byte, XOR it with 0x21, and pass it to the higher layer. The net result is that you completely remove all XON and XOFF characters from the user data stream, so that you can unambiguously use them for flow control purposes. This feature has been in the V-series modems from the very beginning, because Hayes wanted to be able to support applications that require fully-transparent data transfer but can't use RTS/CTS (wqhich is exactly your situation). -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net