sl@wimsey.bc.ca (Stuart Lynne) (04/13/91)
In article <1991Apr12.132116.11546@hobbit.gandalf.ca> dcarr@hobbit.gandalf.ca (Dave Carr) writes: >In <3908.280363d4@hayes.uucp> tnixon@hayes.uucp writes: > >>I always advise people to compress before sending if possible. An >>offline compression program can make multiple passes over the data >>and really optimize the compression, while a modem only has one shot >>at it. I've just installed a V.32bis/V.42bis on our PPP link and first results are quite suprising. I tried ftp'ing from a fairly close site to see what the difference between each of the operating modes where. To summarize: DTE speed: 19.2 Protocol: PPP with Van Jacobsen Header compression Text file: 377799 bytes, an ls-lR file Compressed: 79463 bytes Ping: 10 bytes, 20 times to router on far side of PPP link Link Text Compressed Ping sec/kbps sec/kbps min/avg/max V.32bis 307/1.2 64/1.2 160/211/448 V.32bis/MNP5 230/1.6 64/1.2 240/263/384 V.32bis/V.42bis 230/1.6 50/1.5 240/251/272 Results 1. If latency is a problem the best results are obtained by just running in V.32bis with no attempt to add MNP or V.42. 2. Both MNP5 and V.42bis achieve good results for non random ASCII text files. 3. V.42bis suprisingly did quite well with the compressed file. 4. I was pressed for time so was unable to do the tests more than twice for each transfer, so take the above with a grain of salt. Conclusions Up till now running at 9600 bps with V.32 I've taken the attitude that latency was a problem. Our main use of this link is two nntp feeds, one from a local (across town) site and one non-local (far side of continent) site. We also handle mail for a fair number of local sites. With the odd ftp transfer thrown in. The subjective feeling was that the additional benefits from MNP5 compression did not make up for the large increases in latency (several hundreds of milli-seconds). So we ran V.32 in raw mode. Not reliable mode with MNP. Given the above results, with the latency differences being about 60 milli-seconds, V.42bis seeming to be able to handle compressed files I'm going to use V.32bis and V.42bis for now. The average latency on the new link will still be better than on the old V.32 link, and all data transfers should be between 50-100% faster. BTW the subjective feeling is that the link seems a lot faster. FTP logon's seem to be made faster. And the FTP sessions don't seem to die as often. (With two sites constantly dunning you with nntp transfer requests, and handling about 500 SMTP conversations a day, at 9600 bps FTP was usually quite slow, and often seemed to die just by being too slow, the dreaded message "Netin: connection reset by peer" was often seen.) If anyone out there has tried ftp'ing from here in the past and has the oppourtunity to try again I'd appreciate any comments comparing responsiveness. -- Stuart Lynne Computer Signal Corporation, Canada ...!van-bc!sl 604-937-7785 604-937-7718(fax) sl@wimsey.bc.ca
brian@telebit.com (Brian Lloyd) (04/14/91)
The Telebit NetBlazer is a dial-up IP router that uses SLIP or PPP as a framing protocol. We have spent quite a bit of time characterizing the performance of SLIP and PPP with or without V.42 and V.42bis. The previous posting indicated results that agree quite closely with what we see both in our lab and in real life. With a NetBlazer driving a single T-1600 modem with traditional (no VJ header compression) SLIP and the modems running V.42 and V.42bis I normally see 1.5KB/s to 1.7KB/s throughput. If the data is really compressible I have seen performance as high as 2.6KB/s. These are the values reported by FTP so it is real-world throughput. As a result of our experience, we have the NetBlazer configure the modem for V.42 and V.42bis by default. The latency is usually acceptable for TELNET, rlogin, or other interactive activity (at least it is for me and I am pretty picky). -- 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
news@m2xenix.psg.com (Randy Bush) (04/14/91)
Stuart, timings in your measurements do not agree with ours down here in the Portland SLIP metronet, RAINet. Or were your figures Imperial CPS? For a large text file, with V.42bis over straight V.32, we get 1.7kcps using PC-Route with serial ports locked at 19.2kb and Intel 9600EX modems. We believe that the limiting factor here is the serial port speed, as 1.7cps is about 19.2 minus (non-compressed) headers. We're planning to experiment with locking the ports at 38.4 when we get some faster PC-Router motherboards, especially as we move towards V.32bis. -- Randy Bush / news@psg.com / ..!uunet!m2xenix!news
bob@MorningStar.Com (Bob Sutterfield) (04/16/91)
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.