[comp.sys.ibm.pc] Kermit 2.30 part 4 / 4

johnk@auscso.UUCP (01/24/88)

First, most sites compress news before sending it.  (in fact the standard way
is to use sendbatch to send compressed news to other systems)
second, compress makes arced files BIGGER!!!!! it's true, believe it or not!
-- 
John Knutson   {ihnp4,allegra,ut-sally}!ut-emx!auscso!johnk
	Living is easy with eyes closed, misunderstanding all you see
	Communicating, like in the good ol' days.
Disclaimer:  Don't look at me, I don't even work here!

madd@bu-cs.BU.EDU (Jim Frost) (01/26/88)

In article <1339@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes:
>In article <3243@psuvax1.psu.edu> wcf@psuhcx (Bill Fenner) writes:
>>EVERYBODY- Unless it's going to make the file bigger (only when the file is
>>about 5 bytes long), ARC THE FILES BEFORE YOU UUENCODE!  You'll save the
>>net a LOT of money!  If you post .EXE or .COM files, you're contributing
>>to the downfall of comp.binaries.ibm.pc!
>EVERYBODY - don't listen to this.  Every major long distance link that is
>cost conscious uses lempel-ziv compression on transmitted files.   If
>Arc+LZ gives better than LZ, it's marginal.  Sometimes it is worse.
>
>Doing ARC first does save disk space, I will say that for it, but it
>doesn't do much for transmission time.

I'll respond to this by pulling my article out of comp.binaries.pc:

-- cut here --
From: madd@bu-cs.BU.EDU (Jim Frost)
Newsgroups: comp.binaries.ibm.pc
Subject: Re: Kermit 2.30 part 4 / 4 (really: compression of ARC files)
Message-ID: <19173@bu-cs.BU.EDU>
Date: 24 Jan 88 18:49:33 GMT
References: <5004@bellcore.bellcore.com> <3243@psuvax1.psu.edu> <2526@auscso.UUCP>

In article <2526@auscso.UUCP> johnk@auscso.UUCP (John Knutson) writes:
>First, most sites compress news before sending it.  (in fact the standard way
>is to use sendbatch to send compressed news to other systems)
>second, compress makes arced files BIGGER!!!!! it's true, believe it or not!

This is not necessarily, or even usually, true.  ARCing an ARC file
makes the resultant file bigger (providing that the user didn't force
the ARC format to non-optimal), but ARC files submitted over the net
are uuencoded, which expands them quite a bit (4 bytes for every 3, or
a 33% increase not including headers).  Since the file has been
expanded, it is subject to space savings if compression techniques are
used.  To verify that ARC files actually would save space, I ran some
tests on an actual ARC file on our system:

	Straight files:            112k (binary, can't mail)
	uuencoded files:           155k
	compressed uuencoded files: 94k

	ARC format:                 77k (binary, can't mail)
	uuencoded ARC:             120k
	compressed uuencoded ARC:   91k

I was unable to compress the actual ARC file because compress
determined that the ARC file would be bigger compressed and refused to
compress it, which is really what you would expect it to do anyway.

From the results, it is obvious that with an unARCed file, you have to
send some 35k more if the file was unARCed and transmitted in
uuencoded format, or 3k more if the uuencoded files were sent through
compress.  Note that part of the ARC file was a document and this
compressed very efficiently; you still saved 3k if it were ARCed
first.

In conclusion, ARCed files do save space and therefore time and money,
even on systems that use compression in their mailers.

jim frost
madd@bu-it.bu.edu

farren@gethen.UUCP (Michael J. Farren) (01/29/88)

In article <19235@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes:
>
>In conclusion, ARCed files do save space and therefore time and money,
>even on systems that use compression in their mailers.

I hate to see this going around again - while I posted facts and figures
some time ago, it would seem that people either didn't pay attention or
never heard:  ARCing files, if AND ONLY IF they are exclusively binary
files with minimal plaintext content, does not have a significant impact
one way or the other on net transmission costs.  If anything, the ARCed
files save a few percent.

If, however, the ARCs contain text files, the efficiency loss is
just plain enormous (on the order of 75 - 100 percent larger transmitted
files).  Do NOT post ARCs which are made up of text files.  Ever.
The standard news compression does a MUCH better job on text than
ARC/uuencode can ever hope to.  Really.

-- 
Michael J. Farren             | "INVESTIGATE your point of view, don't just 
{ucbvax, uunet, hoptoad}!     | dogmatize it!  Reflect on it and re-evaluate
        unisoft!gethen!farren | it.  You may want to change your mind someday."
gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame 

jbs@eddie.MIT.EDU (Jeff Siegal) (01/31/88)

In article <1339@looking.UUCP> brad@looking.UUCP (Brad Templeton) writes:
>In article <3243@psuvax1.psu.edu> wcf@psuhcx (Bill Fenner) writes:
>>[...]ARC THE FILES BEFORE YOU UUENCODE! 
>EVERYBODY - don't listen to this.

The cost factors are small.  Both compression programs are pretty
good.  Many sites don't use compress on their news batches because it
adds to the system load, even though it reduces phone time.  In this
case, arc'ed files do save money.

There is another factor that I think is more important.  If you arc
the files first, you can use the arc t option to get some assurance
that things were not munged along the way.

Jeff

hardin@hpindda.HP.COM (John Hardin) (02/04/88)

>If, however, the ARCs contain text files, the efficiency loss is
>just plain enormous (on the order of 75 - 100 percent larger transmitted
>files).  Do NOT post ARCs which are made up of text files.  Ever.
>The standard news compression does a MUCH better job on text than
>ARC/uuencode can ever hope to.  Really.

What do you suggest for posting groups of small text files to be
submitted together (e.g., source modules).  Surely you are not
suggesting posting each separately?!

John Hardin