Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!bogstad From: bogstad@brl-smoke.ARPA (William Bogstad ) Newsgroups: net.sources.d Subject: Re: Posting compressed info Message-ID: Date: Thu, 28-Aug-86 14:10:17 EDT Article-I.D.: brl-smok.3388 Posted: Thu Aug 28 14:10:17 1986 Date-Received: Fri, 29-Aug-86 18:45:54 EDT References: Reply-To: bogstad@brl.arpa (William Bogstad (JHU|mike) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 82 Keywords: cost, compress, uuencode [I apologize in advance to the people on the ARPANET who will get this in UNIX-SOURCES. Maybe there should be a UNIX-SOURCES-D mailing list?] I decided to take a look at the effect of compress as suggested. I used as a sample the full text of the Aug 12th Senate bill 2575. (Note this was never posted to the net, but is a result of the two seperate postings made by myself and Glenn Tenney.) I used the following notation for the file names: Roots Suffix ===== ====== whole - the original text .Z - compressed (b16 -default on vax?) part? - one of a # of parts .uu - uuencoded total - sum of all parts (read from left to right with each (not always the same as whole) conversion being done in turn.) [A list of files and their sizes is at the end of this posting.] The first thing to note is that because the text as a whole is >64K it should not be posted uncompressed as a single message. Too many sites truncate messages at that limit to make this a viable option. The figures also indicate that if you are going to post a uuencoded compressed message it is better to compress the whole rather then breaking it into parts. The figures to compare are for whole.Z.uu and total.Z.uu. You now have to compare a single compressed posting with two uncompressed postings. For sites that do not use compression on their newsfeeds the gain is large (total - whole.Z ~= 40K). Sites that do compress their news feeds have a small loss (total.Z - whole.Z.uu.Z ~= 5.5K). Using the figures from mod.newslists of 800 baud throughput and $.15 a minute cost this loss per such feed is ~= 18 cents. Thus far we have looked at the effects of compression on the cost of transmission. In addition, we have assummed that any sites that "pay" for their calls will use compression on their newsfeeds and that line charges are the only cost. Let's add some "reasonable?" figures for disk storage. I will use the following figures: $10,000 for 400M drive, 3 year life span, 2 week expiration times. This translates to $1 for 40K for 3 years (no I didn't fudge the figures). 2 weeks is 1/78 of that period which gives a cost differential (for EVERY site) of 1.2 cents. Many sites use longer expiration times on sources so the average could easily be higher. I'd like to come to a conclusion here, but I'm afraid I still can't do so. I don't know what the ratio of long distance (LD) feeds to sites is and I don't know the ratio of compressed LD to non-compressed LD sites is. In addition, there is the cost for the CPU time used for the per site compression/uncompression and actual transmission of the feed. Many sites, however, can "hide" these costs and only have to justify their LD charges. Perhaps the whole thing should hinge on the ease of use. Some people apparently do not have access to compress and uuencode or have machines that can not handle the larger -b values which is the default with compress on many machines. For myself, I will probably post straight text in the future in order to avoid having to mail copies to people who can't use the original. I do think, however, that before a net-wide rule (suggestion?) is made that these other factors be considered. If you do use compress be sure to use the -b 12 option so anyone with compress can read it. It really doesn't save much additional space to use the larger bit values. 70490 whole 28524 whole.Z 39320 whole.Z.uu 35934 whole.Z.uu.Z 38669 part1 70490 total 17013 part1.Z 30647 total.Z 23466 part1.Z.uu 42276 total.Z.uu 21748 part1.Z.uu.Z 39449 total.Z.uu.Z 31821 part2 13634 part2.Z 18810 part2.Z.uu 17701 part2.Z.uu.Z Bill Bogstad bogstad@hopkins-eecs-bravo.arpa bogstad@brl-smoke.arpa