rbraun@spdcc.COM (Rich Braun) (04/12/91)
There has been some discussion of CTS/RTS in comp.unix.sysv386, and I'm in the midst of specifying a SLIP interface for a product under development. One of the requirements is the ability to communicate with SLIP running on virtually any Unix system. SCO's TCP product includes a caveat that SLIP won't work faster than 2400 baud for Unix 3.2.0 or earlier; presumably they've made some fixes to the serial port driver so it will handle faster data rates without flow control. The engineering veep here shudders at the thought of hardware flow control. I'm claiming one should support CTS/RTS in the interest of providing better performance. But he does have a point: I've spent many an hour tearing out my hair making RS-232 interfaces work against odd flavors of equipment, and we don't want our customers to go bald too. So, I pose the question to the net. When designing a new product which supports SLIP, what kind of performance can I expect without flow control against various flavors of Unix? Will I have to get into the business of writing device drivers and/or OEMing "smart" serial cards? Am I crazy to consider developing an interface without RTS/CTS? Is the half-duplex hardware flow control supported by SCO widespread enough that I need to worry about supporting it? Finally, PPP (Point to Point Protocol) seems to address many inadequacies in SLIP. For example, it's possible to use XON/XOFF flow control with PPP, because it remaps control characters out of the range 01-1F. Is PPP catching on quickly, and is it generally expected that new products supporting serial-line IP should also support PPP? (And, can I get a public-domain C implementation?) -rich
brian@telebit.com (Brian Lloyd) (04/12/91)
In article <7275@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >SCO's TCP product includes a caveat that SLIP won't work faster than >2400 baud for Unix 3.2.0 or earlier; presumably they've made some fixes >to the serial port driver so it will handle faster data rates without >flow control. SCO's standard tty drivers for the internal 16450 ports (COM1 and COM2) are pretty poor performers. If you plan to do SLIP I -*<STRONGLY>*- recommend an intelligent serial I/O card or plan to go REEAAALLL SSLLOOWW. >The engineering veep here shudders at the thought of hardware flow >control. I'm claiming one should support CTS/RTS in the interest of >providing better performance. But he does have a point: I've spent >many an hour tearing out my hair making RS-232 interfaces work against >odd flavors of equipment, and we don't want our customers to go bald >too. First, SLIP connections do not stream data that often. If the host gets busy it may not have time to send back the TCP ACKs (assuming you are using TCP atop IP atop SLIP). In that case the sender's window will close and he will stop sending. This gives the busy host time to catch it breath. Given this, it is a matter of buffering in the asy driver on the receiving end and how rapidly the host can empty that buffer. That is the reason that using an intelligent asy board is such a win. The intelligent boards usually have scads of buffer space and the host can spend all of its time processing the packets instead of responding to interrupts. > >So, I pose the question to the net. When designing a new product which >supports SLIP, what kind of performance can I expect without flow >control against various flavors of Unix? I would expect to be able to send and receive at 19,200 bps if the remote host has an intelligent comm board. I could sustain that on a 286 running Microport's SysV/AT UNIX with a Digiboard 8-port intelligent comm board. Our Telebit NetBlazer dial-up IP router will sustain many ports running SLIP or PPP at 57.6Kbps without flow control. We do support RTS/CTS flow control anyway. You don't have to use it but when you need it, it's nice to have it. >Will I have to get into the business of writing device drivers and/or >OEMing "smart" serial cards? Yes, your UNIX hosts will want to have an intelligent serial I/O card. No, you won't need to write the driver since most vendors of the aforementioned cards provide adequate drivers. I don't know about your personal application tho'. >Am I crazy to consider developing an interface without RTS/CTS? Not crazy but think of it as insurance. You will need it some day. > Is the half-duplex hardware flow control supported by SCO widespread >enough that I need to worry about supporting it? I have never seen anyone else use it in the SLIP world. >Finally, PPP (Point to Point Protocol) seems to address many inadequacies >in SLIP. For example, it's possible to use XON/XOFF flow control with >PPP, because it remaps control characters out of the range 01-1F. But most just turn off the character mapping and use hardware flow control, especially when talking to a modem. >Is PPP catching on quickly, Yes, very. Most of the router vendors have adopted PPP for interoperability on their sync links. Telebit, Interactive, FTP, Intercon, and others support async PPP in their products. PPP has many more advantages over SLIP besides the ability to escape the control characters. >and is it generally expected that new products >supporting serial-line IP should also support PPP? ABSOLUTELY!!! >(And, can I get a public-domain C implementation?) Yes. PPP and SLIP are in the KA9Q TCP/IP package. Do an anonymous FTP to ucdavis.edu or possibly thumper.bellcore.com and poke around. This software is not public domain but it is there for you to learn from and you can cut a deal with Phil Karn (karn@thumper.bellcore.com) if you want to do something commercially. -- Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@napa.telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333
aris@tabbs.UUCP (Aris Stathakis) (04/14/91)
In <7275@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >SCO's TCP product includes a caveat that SLIP won't work faster than >2400 baud for Unix 3.2.0 or earlier; presumably they've made some fixes >to the serial port driver so it will handle faster data rates without >flow control. I've used SLIP between an SCO ODT (SCO UNIX 3.2.1) and SCO UNIX 3.2.2 at 38,400 with no problems at all. >Finally, PPP (Point to Point Protocol) seems to address many inadequacies >in SLIP. For example, it's possible to use XON/XOFF flow control with >PPP, because it remaps control characters out of the range 01-1F. Is >PPP catching on quickly, and is it generally expected that new products >supporting serial-line IP should also support PPP? (And, can I get a >public-domain C implementation?) I'd also be interested in info on PPP. Thanks Aris -- Aris Stathakis | Bang: ..!uunet!ddsw1!olsa99!tabbs!aris or aris@tabbs.UUCP - - - Disco is to music what Etch-A-Sketch is to art. -
larry@nstar.rn.com (Larry Snyder) (04/17/91)
brian@telebit.com (Brian Lloyd) writes: >SCO's standard tty drivers for the internal 16450 ports (COM1 and >COM2) are pretty poor performers. If you plan to do SLIP I >-*<STRONGLY>*- recommend an intelligent serial I/O card or plan to go >REEAAALLL SSLLOOWW. Hmm - At least with Interactive if one runs SLIP they need to run it on the stock ASY port. We've tried numerous smartboards and had nothing but problems - and finally we received information that 386/ix has specific hooks in the ASY driver to support SLIP. With a 16550AFN and the buffer enabled (the ASY driver enables the FIFO) throughput is quite good (with the DTE locked at 38400). >Yes, very. Most of the router vendors have adopted PPP for >interoperability on their sync links. Telebit, Interactive, FTP, >Intercon, and others support async PPP in their products. PPP has >many more advantages over SLIP besides the ability to escape the >control characters. Interactive isn't using it in their 2.21 (how about Dell SVR4?) -- Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
misko@abhg.UUCP (William Miskovetz) (04/18/91)
In article <1991Apr17.133255.2117@nstar.rn.com>, larry@nstar.rn.com (Larry Snyder) writes: > > Hmm - At least with Interactive if one runs SLIP they need > to run it on the stock ASY port. We've tried numerous > smartboards and had nothing but problems - and finally > we received information that 386/ix has specific hooks in > the ASY driver to support SLIP. With a 16550AFN and the > buffer enabled (the ASY driver enables the FIFO) throughput > is quite good (with the DTE locked at 38400). This certainly isn't true. I run SLIP on a generic 2 port serial card with 16550As and an APT 8 port card, both using FAS, and SLIP works with no problems. So, ISC's stock ASY driver isn't required. This is with ISC 2.2 and their TCP/IP 1.2. > > >Yes, very. Most of the router vendors have adopted PPP for > >interoperability on their sync links. Telebit, Interactive, FTP, > >Intercon, and others support async PPP in their products. PPP has > >many more advantages over SLIP besides the ability to escape the > >control characters. Has Interactive shipped an update to their TCP/IP that supports PPP? Bill Miskovetz {uunet!lll-winken, apple!mathworks}!abhg!misko misko@mathworks.com abhg!misko@lll-winken.llnl.gov
mah@dec1.wu-wien.ac.at (Michael Haberler) (04/18/91)
In article <1991Apr17.133255.2117@nstar.rn.com>, larry@nstar.rn.com (Larry Snyder) writes: |> brian@telebit.com (Brian Lloyd) writes: |> |> >SCO's standard tty drivers for the internal 16450 ports (COM1 and |> >COM2) are pretty poor performers. If you plan to do SLIP I |> >-*<STRONGLY>*- recommend an intelligent serial I/O card or plan to go |> >REEAAALLL SSLLOOWW. |> |> Hmm - At least with Interactive if one runs SLIP they need |> to run it on the stock ASY port. We've tried numerous |> smartboards and had nothing but problems - and finally Hmm - I have running SLIP over the FAS2.08 driver running fine. The only glitch is with ICMP echo requests generated with ping - the sometimes have checksum errors. TCP and UDP work fine. - michael