domo@tsa.co.uk (Dominic Dunlop) (07/19/90)
[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 <andrew@ramona.cary.nc.us> 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 <sung@concert.net> 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 <grr@cbmvax> 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 <dean@coplex.UUCP> 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 <larry@nstar.uucp> 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 <mike@anomaly.sbs.com> 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 <vjs@rhyolite.wpd.sgi.com> 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
datri@convex.com (Anthony A. Datri) (07/20/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 I've been led to believe that on-the-fly compression adds some latency to the connection. If you're using the uucp g spoofing, though, I imagine that you might not notice. For most people who get news, the volume of compressed news batches is higher than that of mail. If you've got a uucp that supports grading, I imagine you might be able to make one call at mail grade, then make another call at news grade, although I'm still not sure that it'd be worth the hassle, since the typical mail transactions involve small files, and I imagine that any gains would be small compared to the setup overhead from uucico. --
scs@lokkur.dexter.mi.us (Steve Simmons) (07/29/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? Wayne Sung <sung@concert.net> 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). I post this with hesitance, as it's based on three-year-old memories of a casual conversation. So take it with a big grain of salt: Peter Honeyman said that when you add in the overhead of the PEP protocol and the uucp conversations on both ends, maximum uucp thruput on a pair of trailblazers is in the high 14000s. This is pretty consistant with Sung's experience, but does say that he'll get no improvement with faster terminal servers.
tim@dciem.dciem.dnd.ca (Tim Pointing) (08/02/90)
In article <1990Jul29.020727.20158@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes: >I post this with hesitance, as it's based on three-year-old memories >of a casual conversation. So take it with a big grain of salt: Peter >Honeyman said that when you add in the overhead of the PEP protocol >and the uucp conversations on both ends, maximum uucp thruput on a >pair of trailblazers is in the high 14000s. Hmmm... that seems awfully close to the bit-rate of the modems (maximum of about 14400 bit/sec.) Just a coincidence? I don't think so. UUCP's "g" protocol seems to take up about 10% of the bandwidth (witness 110 bps over 1200 bps modems.) If one connects the TB to the hosts at 19200 bps, you should be able to get ~ 90% * 19200 = 17280 bps (that's bits of real user-data). This is higher than the bit-rate of the TB modems, I hear you say. If, however, the compression in the TB runs fast enough, and only text is sent (not already-compressed) data, you should be able to get a theoretical maximum information-transfer-rate of around 28000 bps [14400 / (1.0 - 0.5) ... the "0.5" being the compression factor - 50% is about right for text.] Thus, you *should* be limited by the 19200 bit-rate to the modems. Again, this assumes very fast compression on straight text or news. -- Tim Pointing, DCIEM {decvax,attcan,watmath,...}!utzoo!dciem!tim uunet!csri.toronto.edu!dciem!tim or nrcaer!dciem!tim tim%ben@zorac.dciem.dnd.ca or tim@ben.dciem.dnd.ca