do not use error correction or compression. (they will slow you down) and tcp does it's own error correction. as for 160ms round trip times that is acceptable for slip.
I don't know about you, but 160ms *is* objectionable to me when typing on a character-at-a-time telnet connection. And several people I've tried to introduce to demand-dialed SLIP (instead of hogging annex ports for hours with idle dumb terminals) have also complained about the delay. BTW, there's another problem with V.42bis compression that I haven't mentioned yet. When you enable compression, most modems suck in several seconds' worth of transmit data before they drop CTS to flow control the host (this assumes the DTE speed is considerably faster than the line speed, as it needs to be to get the most out of the compression). This is no problem if you're sending a large file with, say, ZMODEM; presumably the modem buffers up all this data so it can figure out whether to compress it or not. But this creates nasty delay problems for SLIP/PPP when you try to mix bulk and interactive traffic streams. Even if your router gives interactive (e.g., Telnet) packets priority over bulk (e.g., FTP) traffic in its own interface send queues, it can't do anything about the data that's already gone to the modem. So if the modem buffers up 2 seconds of FTP data, then your telnet packets will see 2 second delays even if it they have unconditional priority in the router over your big background FTP transfer. Worse still, some modems seem to buffer up all this data even when you disable V.42bis compression. Sigh. I point this out because many people would like to multiplex secure voice with IP data over their SLIP links. This lets you use a single phone line for voice and data simultaneously (especially if you have a variable rate vocoder), and it lets you use the Internet for voice. Not only does this let you bypass the long distance network, but it would make a pen register on your modem line almost useless. It would just show that you frequently call a local SLIP server to which you presumably have legitimate access. :-) But there are some problems yet to be solved. I'm rapidly coming to the conclusion that the only way around the SLIP/PPP modem buffer/delay problems is to speak raw synchronous data to the modems, even to the point of implementing V.42bis and HDLC in the host computer instead of using the modem's implementation. Phil