Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!homxb!houxm!whuts!tes
From: tes@whuts.UUCP
Newsgroups: comp.sys.ibm.pc,comp.sys.att
Subject: Perf./Comp. Tests ARC/PKARC was: Numerous requests ...
Message-ID: <1743@whuts.UUCP>
Date: Fri, 10-Apr-87 15:17:56 EST
Article-I.D.: whuts.1743
Posted: Fri Apr 10 15:17:56 1987
Date-Received: Sat, 11-Apr-87 20:44:38 EST
References: <274@cup.portal.com>, <58200031@gorgo.UUCP> <433@csm9a.UUCP>
Organization: AT&T Bell Laboratories
Lines: 65
Xref: utgpu comp.sys.ibm.pc:2856 comp.sys.att:296
Summary: Performance/Compatibility TESTS! ARC/PKARC!

In article <433@csm9a.UUCP>, japplega@csm9a.UUCP (Joe Applegate) writes:
> The latest version of
> ARC from SEA is 5.20...  Most BBS's now carry ARC520.COM, 
> which is the self unarcing version from SEA.
> 
> As to PKARC, I am currently discouraging the use of PKARC to archive files
> until it is modified to use another extension.  PKARC archives are NOT
> compatible with ARC 5.12 or 5.20!!!  This is seriously complicated by the
> fact that it's files are labeled with the same extension!  ARC is an industry
> standard... PKARC is not!
Running in where angels fear to tread.....

This a re-run of the quarterly ARC-wars.  Approximately once a 
quarter either PKware or SEA issues a new release, claiming 
instant victory.  It has not been true in the past.  Each package
has trade offs.  To check out the new releases, I downloaded both
as both had gone through at least two upgrades since I last
bothered, and ran a test.....

The test was of 20 files of legitimate text material totalling
1,148,280 bytes.  Text material was selected because 90%+ of
the creative effort of engineers (and related professions) is 
in text (or source code which is the same thing).  I ran ARC,
PKARC (old compress), and PKARC (native mode).  The "old compress"
is a concession by PKware to allow de-ARCing by ARC.  The comments
feature of PKARC neither hindered nor helped de-ARCing.  I did
not check for truncation of comments.  With this background,
here are the results:

Version     |Cmnd Line  | Time  |Arc Size-Bytes |Can Be de-Arced by?
            |           |       |        (and %)| arc -e|| pkxarc
===================================================================
arc520.com  |arc -a     |17.9min|488,473 (42.6%)| yes   ||  yes
pkx24a20.com|pkarc /oc -a|3.2min|507,720 (44.4%)| yes   ||  yes
pkx24a20.com|pkarc -a   | 3.2min|479,524 (41.9%)| NO!   ||  yes
====================================================================

Notes:
1.  Version is the file name of the self-de-arcing file you
download.  NEVER accept other forms, may be a TROJAN.
2.  Versions are the latest announced by respective companies.
3.  Remember the "pkarc /oc" can be considered the "SEA-compatible"
mode.  PKware has released a patch that reverses the meaning 
of the compatibility mode, making "native mode" the option.
4.  The size differences are trivial, see below for analysis.
5.  The time differences are not trivial.

Conclusions:
1. This "incompatibility" issue is silly.  As pkarc is the 
"follower" package, it should maintain compatibility in
BOTH directions.  As the originator, SEA sets the standard,
not PKware.
2. I personally do not upload to BBS (have nothing of interest)
but anyone who does should consider it a matter of PROFESSIONALISM
to upload ONLY SEA-compatible files.
3. The difference in sizes is trivial, less than 2.5%.  If that
makes a difference to you, I suspect that the real problem is
that you have outgrown your hard disk.
4. Looking at it from another viewpoint, the size differences
create LESS THAN 5 minutes difference in connect time at 1200bps.
(my true transfer rate at 1200bps is 99 bytes per second).

Recommendation:
Use PKARC/PKXARC in the "/oc" mode to save time while remaining
truly compatible.