Xref: utzoo comp.mail.uucp:4758 comp.dcom.modems:6294 Path: utzoo!attcan!uunet!mcsun!ukc!axion!tsa!domo From: domo@tsa.co.uk (Dominic Dunlop) Newsgroups: comp.mail.uucp,comp.dcom.modems Subject: What use is Trailblazer compression -- Summary of replies (long) Summary: Probably not a lot Message-ID: <1990Jul19.154334.27957@tsa.co.uk> Date: 19 Jul 90 15:43:34 GMT References: <1990Jul4.195351.9324@tsa.co.uk> Reply-To: domo@tsa.co.uk (Dominic Dunlop) Organization: The Standard Answer Ltd. Lines: 172 [Apologies if this is a duplicate posting. Pretty sure that problems with my newsfeed prevented these pearls from reaching the net two days ago.] I started this thread off on 4th July, and it generated sufficient replies and interest that I'm summarizing herewith. Here's what I asked: % 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? The balance of opinion seems to be that Trailblazer compression is rarely worth the bother of working out whether you need it or not. Anyway... -- Andrew Ernest said > It's only a win if data moves between the modem and computer > substantially faster than it moves over the phone line. With a good > clean line, the blazers can ofter pump more data between themselves > than they can pump in and out of the computers they are connected to > (especially true when the systems are either loaded or equipped with > crappy async hardware or device drivers). Under such conditions, > compression won't gain you anything. > Well, I'd not thought of that obvious point, and it means that compression won't buy me much anyway. I replied % Thanks for your input. Your point about the async interface being the % bottleneck is well taken: until Apple ships me A/UX 2.0 (Real Soon Now) % I'm in that situation. Andrew added > If you are dealing with a slow overseas connection, compression might > gain you something. Really, you need to do your own testing (it's not > that hard). Try it both ways and see what's best for your application. > > Compression has been completely worthless for me but I only call > within the U.S. I call only in the U.K. (except on very rare occasions), so can't comment. -- Ronald.Khoo@robobar.Co.Uk made the same point about interface speed: > Well, first of all, you aren't going to win much unless both TB's are > driven by computers which can do 19200 with no hassle. > Ronald's second point about message size is mad in George Robbin's comments below. Ronald added: > > The real win would be if you could batch multiple mail messages into a > BSMTP batch and just uux that instead. I _think_ smail 3.1 has some > support for it -- at least I saw some appropriately named files in > the distribution... I know of. I suppose a MMDF channel could be > written to support this... Yes, this is a good idea, but I'm not about to do it. BSMTP stands for Batched Simple Message Transfer Protocol, a part of the TCP/IP family. While TCP/IP and friends are currently little-used for wide-area communications, and still less for dial-up in Europe, using uucp as a transport mechanism for mail batches is a wrinkle I hadn't thought of. -- Wayne Sung said > This is my own experience: from home to work I just about can not get the > full link speed of Trailblazers (it usually winds up at just under 15000 > rather than the 18000 you can get). The terminal server I eventually get > to can do 19200. If I do not use compression in the modems, I will lose > characters doing things like reading news. With compression on I do not. > So I would say for text there is definitely some gain. Subjectively it also > seems the output flow is a little smoother. There is not much effect on > single character handling. I'm not interested in interactive use, but this information should help you if you are. I'm told Trailblazers go great with X terminals, unless you start throwing too many bitmaps around. But bitmaps are susceptible to compression -- see the next reply. -- George Robbins wrote: > 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. > That's true, but I quite often send large lumps of mail, and so might just gain the benefit of compression (assuming I could feed the modem fast enough). (See also Vernon Schryver's comments below.) > 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. Another respondent who had been running a news system on 80286 Xenix (sorry, I've lost the posting) This may be useful if your computer lacks horse-power -- have that 10 MHz 68000 in the Trailblazer do the work of compression and decompresson, rather than the over-stretched host CPU. George continued: > 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. Thought I heard a rumour that some future Trailblazer model or firmware release would support 38.4 kbs on the interface. Confirmation, denial or comments, anybody? -- Dean Brooks wrote: > 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). Turns out that running LZW compression over data already compressed with LZW (effectively what happens when compressed news batches are transmitted across a Trailblazer connection with compression enables) causes a remarkable ballooning of data bits, as I found out when replying to: -- Larry Snyder wrote: > 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. I replied: % Thanks for your input. Not surprised that throughput dropped when you % enabled compression when exchanging already-compressed news batches. Just % running a trivial test: [actually, my reply to Larry used different data] $ cat ~news/junk/* | wc -c 102452 $ cat ~news/junk/* | compress -b 12 | wc -c 61432 $ cat ~news/junk/* | compress -b 12 | compress -b 12 | wc -c 83146 As far as I recall, the Trailblazer, like default news batching, uses 12-bit LZW compression, so compress -b 12 should give a fair approximation. I knew that compressing compressed data was a Bad Idea, but didn't realise that so much overhead was added (although throughput should still be better than with no compression whatever). -- Michael P. Deignan wrote, as if to confirm: > There is a performance decrease if you use compression for batched news. > > If you are using plain text, there is definitely a performance increase. > Your actual thruput will vary, but I normally get about 1400cps with > text compression, and 1200cps with uncompressed news. -- Vernon Schryver wrote: > > 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. That's true, although of course exactly what you have to fiddle with depends on the provenance of your uucp. I think it's Vernon's advice that I'll take, just as soon as I can talk to my Trailblazer at 19.2kbs, but thanks to all who replied. -- Dominic Dunlop