Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mstar!mstar.morningstar.com!bob From: bob@MorningStar.Com (Bob Sutterfield) Newsgroups: comp.dcom.modems Subject: Re: PPP and V.32bis/V.42bis (was Re: Uses of V.42 (bis?) data compression) Message-ID: Date: 15 Apr 91 18:26:55 GMT References: <10334@pitt.UUCP> <3908.280363d4@hayes.uucp> <1991Apr12.132116.11546@hobbit.gandalf.ca> <1991Apr13.070324.10288@wimsey.bc.ca> Sender: usenet@MorningStar.COM (USENET Administrator) Reply-To: bob@MorningStar.Com (Bob Sutterfield) Organization: Morning Star Technologies Lines: 35 In-Reply-To: sl@wimsey.bc.ca's message of 13 Apr 91 07:03:24 GMT In article <1991Apr13.070324.10288@wimsey.bc.ca> sl@wimsey.bc.ca (Stuart Lynne) writes: DTE speed: 19.2 Link Text Compressed Ping sec/kbps sec/kbps min/avg/max V.32bis/V.42bis 230/1.6 50/1.5 240/251/272 I see 1.7-2.8 Kbytes/sec using plain old V.32/V.42bis with the DTEs at 38400 to transfer a SPARC kernel (uncompressed). The 1.7 is the overall speed as reported by my ftp(1) client, and the 2.8 is my observation of how fast the arriving file grows, particularly during the section toward the end that's more compressible. My rate drops to 1.5-1.6 Kbps overall when at least one end is running at 19200, just as you report. Have you tried V.32bis/V.42bis with the DTEs at 38400? I suspect you'd see another dramatic improvement, just by keeping the modems' UARTs busy and the compression buffers full. I predict your observed base rate will go above 2.0 Kbps, with gusts well above 3.0. Of course, to keep the modems busy, you'd need a sustainable DTE rate of 57600 (14400 for V.32bis times 4 for the optimal V.42bis compression ratio), which isn't commonly available on UNIX systems. I'm also curious what you see when simultaneously transferring files in both directions across the same link. My rate goes from 1.7-2.8 down to 1.5-2.2, for a pretty reasonable 12-22% degradation. I wonder whether V.32bis' higher basic carrier speed would provide correspondingly better performance under sadistic load conditions? Up till now running at 9600 bps with V.32 I've taken the attitude that latency was a problem. Without looking as closely at the situation as you have, I wouldn't have thought that latency would be much of a problem if both ends of the transaction are running a modern TCP with RFC1072 rolled in. You're probably just using up the DTE rate.