Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!ut-ngp!werner From: werner@ut-ngp.UUCP (Werner Uhrig) Newsgroups: net.news,net.micro.mac Subject: Backbone automatic news-compression question ... Message-ID: <4012@ut-ngp.UUCP> Date: Fri, 19-Sep-86 11:43:42 EDT Article-I.D.: ut-ngp.4012 Posted: Fri Sep 19 11:43:42 1986 Date-Received: Sat, 20-Sep-86 01:21:42 EDT Organization: UTexas Computation Center, Austin, Texas Lines: 88 Keywords: question [regarding] compression [of] news [for] transmission Xref: mnetor net.news:2035 net.micro.mac:7088 Follow-Up-To: net.news I'd like a clarification or poll your opinion on the following matter: It has been mentioned several times (though I don't remember neither context nor details) that several sites compress the news for transmission for efficiency reasons, which makes perfectly good sense to me and I'd expect that more and more machines will use this scheme. Now, it has also been said that it would, therefore, make no sense for users to apply their own compression before posting, because that would defeat the automatic news-compression and cause it to *INCREASE* the time it would take to transmit. Now, in net.micro.mac we currently have a discussion about user-compression of articles containing large text, sources, hexed executables, whatever using a program called PackIt, which comes with 3 features: 1) make one file out of several (because they belong together for some reason) 2) compress a file or files (note that this makes sense for a single file) 3) encrypt a file or files The following arguments have been made: 1) doing encryption makes no sense for public postings (and I agree) 2) BinHexing stuff makes always sense to detect errors introduced during transmission (I agree again) 3) making one file out of several files belonging together is desirable. (I agree with that, except if the resulting file would be too large for one posting and would, therefore, have to be broken up into separate articles, in which case I sometimes do not pack everything into one file, even if individual files are large enough to require breaking it up into multiple articles anyway; but I don't feel strongly about this) AND NOW THE ONE I HAVE PROBLEMS WITH: 4) using the compression feature (which saves about 20% on average) has been questioned with the argument that this would cause the Backbone news transmission compression algorithm to get defeated. THE QUESTION: defeated? increased transmission length? what exactly happens? and is the loss there minor enough to justify the gains all over the net? CONSIDER: If I pack and compress on my MAC before binhexing, the file which I end up uploading is about 20% smaller. Therefore, I save 20% upload time and save all sites that do not have news-compression installed 20% transmission time. Plus, I save 20% diskspace everywhere the article get archived on disk, temporarily or permanently (also on back-up tapes). Also, those folks that download to their Mac save 20% download-time as well as storage space on the Mac-disk. MY OPINION, based on a lack of details about the backbone compression algorithm: I suspect that a) the backbone compression is defeated by packing at the user end. In the sense that no gain in transmission time is made. However, I doubt that transmission is lengthened by much if any. Therefore, the only thing that is lost is the overhead it takes to attempt compression and failing to achieve anything in the process. So what ??!! To have some basis for discussion, let me state an example: I'm about to post a Macintosh executable program, with the following sizes: 26,829 bytes executable program on the Mac 35945 bytes binhexed executable 22,455 bytes compressed executable 30,760 bytes binhexed compressed executable my alternatives are to post either 31K or 36K - given that there are trade-offs, what is the BETTER way to go in your opinion? There is one additional point to consider: The version of the program that compresses is SHAREWARE which was a reason not to post compressed stuff, as it basically forced the receiving end to uncompress and pay for the program (to stay honest) - but a public domain program has since been written by someone that does the uncompressing, but not the compressing, so the receiving end is now without the burden of "pay or feel guilty" ... ---Werner @ngp.cc.utexas.edu @ut-ngp.UUCP PS: Follow-up articles are redirected to net.news and will not appear in net.micro.mac.