was@gdwb.oz.au (Warren Stokes) (01/15/91)
This subject relates to SPARCstation 1, 1+ and 2. I would like to run my MNP5 modem efficiently. This means running the tty line at a higher speed than the link speed. Obviously I need to have hardware flow control. I have noticed that under SunOS 4.1 and 4.1.1 when I set crtscts, characters received are thrown away. This presents no problem with printers since when you are running crtscts you don`t expect to receive any characters. This can be demonstrated by using a D-connector with pin 4 linked to pin 5 and pin 2 linked to pin 3. With a an RS232 tester on the port and a remote file entry like: test:\ dv=/dev/ttya:br#9600:hf: I can tip to the port and see any characters typed go out (and back in) but they don`t make it to the screen. Take out the hf and it works fine. I think it is a driver problem. Has anyone else seen this problem? Can anyone help me with a fix? Thanks Warren Stokes was@gdwb.OZ.AU
guy@uunet.uu.net (Guy Harris) (01/19/91)
>I would like to run my MNP5 modem efficiently. This means running the tty >line at a higher speed than the link speed. Obviously I need to have >hardware flow control. I have noticed that under SunOS 4.1 and 4.1.1 when >I set crtscts, characters received are thrown away. Yup. That's what you should expect; "crtscts" implements *hardware* flow control, i.e. flow control implemented by the serial port *hardware*, and the serial port *hardware* only lets the device receiving data *from* the Sun control the flow of data *from* the Sun - it doesn't let the Sun control the flow of data *into* it. (If I ever find the person who first dubbed flow control done - perhaps in software - by using various modem control lines "hardware flow control", I'm going to shoot them; unfortunately, everybody else seems to have picked up that usage from them....) The only *software* flow control SunOS implements is XON/XOFF flow control; it doesn't implement bi-directional RTS/CTS flow control (wherein the Sun can drop RTS to ask the device to stop sending data) - that wouldn't be hardware flow control, 'cuz the hardware won't do it automatically.
casey@gauss.llnl.gov (Casey Leedom) (01/22/91)
| From: auspex!guy@uunet.uu.net (Guy Harris) | | The only *software* flow control SunOS implements is XON/XOFF flow | control; it doesn't implement bi-directional RTS/CTS flow control (wherein | the Sun can drop RTS to ask the device to stop sending data) - that | wouldn't be hardware flow control, 'cuz the hardware won't do it | automatically. I can't quite tell, but it sounds like you're complaining about RTS/CTS flow control and not Sun's hardware. RTS/CTS flow control is *far better* than XON/XOFF flow control for a number of reasons: 1. RTS/CTS flow control enables you to set up a completely transparent channel. 2. If an XON or XOFF is missed for any reason in software flow control, the channel can lock up. (This won't happen with RTS/CTS signaling unless the hardware is designed particularly badly.) If full receiver buffers can't trigger lowering RTS, the problem sounds like it's with the Sun hardware, not the signalling mechanism. But problems like this aren't unique to Sun. Unix tty drivers have never been very good. One of the reasons we finally gave up entirely on hooking our high speed modem pool to a Unix machine and bought a good terminal server instead. Casey