domo@tsa.co.uk (Dominic Dunlop) (07/05/90)
Is Trailblazer compress any use with uucp for mail transfer? Although I'm pretty sure it would be counter-productive with compressed news batches, is there likely to be any increase in throughput if I have my Trailblazer attempt to negotiate compression when exchanging plaintext mail with sites which are not newsfeeds? Has anybody run tests? Was it a win? -- Dominic Dunlop
grr@cbmvax.commodore.com (George Robbins) (07/05/90)
In article <1990Jul4.195351.9324@tsa.co.uk> domo@tsa.co.uk (Dominic Dunlop) writes: > Is Trailblazer compress any use with uucp for mail transfer? Although I'm > pretty sure it would be counter-productive with compressed news batches, is > there likely to be any increase in throughput if I have my Trailblazer > attempt to negotiate compression when exchanging plaintext mail with sites > which are not newsfeeds? Has anybody run tests? Was it a win? It is probably of some benefit, however mail is transfered in two files, one tiny command file and one usually small data file. UUCP queue search and other per file overhead usually swamps any effective transfer rate on this sort of activity. The only way to full honest thruput is to send large compressed news batches or uucp file transfers. I suppose one could try a uncompressed new feed with compression enabled as a lark, but motivation is lacking. The one place where compression in the modem really pays of is sending CAD or DP flavor printouts where there is a lot of redundancy/repetition. Even here, the trailblazer suffers because it doesn't support 38.4 Kbps and the 19.2 Kbps interface rate is too close to the nominal transmission rate to see any impressive compression factors. It would help more on international or other ratty connections that usually see speeds considerably less that 12-14Kbps. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
andy@acorn.co.uk (Andy Ingle) (07/05/90)
I've used the Trailblazer's built-in compression to feed batched but uncompressed news when my overloaded CPU couldn't take on any more compression itself. It certainly works but I didn't run any measured tests to see what the improvement (if any) was. The best arrangement if for an answering modem to always set S110=1 (enable compression if other end agrees) and let the caller decide whether to use compression or not. --Andy Ingle
larry@nstar.uucp (Larry Snyder) (07/05/90)
domo@tsa.co.uk (Dominic Dunlop) writes: >Is Trailblazer compress any use with uucp for mail transfer? Although I'm >pretty sure it would be counter-productive with compressed news batches, is >there likely to be any increase in throughput if I have my Trailblazer >attempt to negotiate compression when exchanging plaintext mail with sites >which are not newsfeeds? Has anybody run tests? Was it a win? Here at nstar, we have our blazer set up with compression disabled since all of our news is compressed likewise all the bbs files. We were at one time (last year in the Xenix 386 days) running with compression enabled in the modems and found that it actually decreased throughput. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA uucp: iuvax!ndmath!nstar!larry -or- larry@nstar Public Access Unix Site (219) 289-3745 / lots of files & free PEP feeds!
dean@coplex.UUCP (Dean Brooks) (07/06/90)
domo@tsa.co.uk (Dominic Dunlop) writes: >Is Trailblazer compress any use with uucp for mail transfer? Although I'm >pretty sure it would be counter-productive with compressed news batches, is >there likely to be any increase in throughput if I have my Trailblazer >attempt to negotiate compression when exchanging plaintext mail with sites >which are not newsfeeds? You are correct about the compressed news batches not gaining any performance. In fact, on compressed files, it could actually hinder performance. However, on plain ascii files, you will gain whatever compression ratio, their algorithm is able to achieve. I would guess around 30% increase, if you are able to get a 30% compression ratio. In most instances, it could only speed the transmission time, not slow it down (unless you are transferring binary files). > Has anybody run tests? Was it a win? Unfortunately I havent ever used compression, as we mainly transfer batched compressed news. However, if you transfer mostly plain ascii files, I would highly recommend its usage; try it for a while, see what performance changes you get on transferring the same files. -- dean@coplex.UUCP Dean A. Brooks Copper Electronics, Inc. Louisville, Ky UUCP: !uunet!coplex!dean
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (07/08/90)
I've found it useful to make some of the links on sgi.sgi.com use compression and some not. Those links where compressed news batches are most common seem to benefit from having it turned off. Others where mail and file transfers dominate benefit from having it turned on. It is easy to switch by adding the necessary commands to the phone number, or in HDB UUCP, by choosing differing ACU-types/Dialers-entries. One often has to do extra fiddling for sites that have odd combinations of PEP tone presentation, v.32, PBX delays after answering and before presenting tones, and so on. A little more hacking to select the correct compression is not a big deal. Vernon Schryver vjs@sgi.com