Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mcdchg!ddsw1!karl From: karl@ddsw1.MCS.COM (Karl Denninger) Newsgroups: news.software.b Subject: Re: dbz is a must! Summary: "C" News is 300-500% faster unpacking here (one bitch enclosed)! Message-ID: <1989Jul9.043700.11769@ddsw1.MCS.COM> Date: 9 Jul 89 04:37:00 GMT References: <1989Jul4.183539.19106@ivucsb.sba.ca.us> <9568@b-tech.ann-arbor.mi.us> Reply-To: karl@ddsw1.MCS.COM (Karl Denninger) Organization: Macro Computer Solutions, Inc., Mundelein, IL Lines: 95 In article <9568@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >In article <1989Jul4.183539.19106@ivucsb.sba.ca.us> todd@ivucsb.sba.ca.us (Todd Day) writes: >> >>Combined with the major speed win of expire, Cnews is a definite >>improvement over Bnews. > >Have you done any tests on how much time Cnews and Bnews take to >completely process one or more batches of news all the way from rnews >to individual articles in the spool directory? My tests indicate that >cnews is slower (due to all the front end scripts and the copy to >in.coming) and I'm interested in other's tests. I may write a fast >front end for relaynews. No way. Then again, we ran "B" news with "spoolnews" on, so the system would copy the files ANYWAYS when first invoked. Thus, no saving or loss there. Now, with that in mind, we have found that 1MB of news, for example, which used to take some 30-40 minutes to process to completion with "B" news now takes less than 10 minutes to do! That's an effective speed increase of some 300-400%. Expire is no contest - speed increases there are somewhere between 300-1000%! I am impressed. I am less impressed with: 1) "C" news articles don't have a "Lines: xxx" header. This stinks, and broke one of our local interface programs in a mysterious way until I finally tracked it down today. Articles which originate from "B" news sites have the header, those which originate on a "C" news site do not. This particular problem is at least slightly serious. 2) "C" news has little or no documentation. For example, "expire" flags had to be discerned by reading the code. I don't mind reading the code (after all, I had to compile and tweak it), but c'mon -- not even a description of the formats in the files themselves, although there is a comment character (#) supported?! That wasn't nice! 3) Some obscure things that you used to be able to do with the "sys" file don't work anymore. In particular, enclosing a set of shell statements in "(" and ")", which used to work in "B" news, fails under "C" news. I had to relocate our "funny items" to a shell script and call that from the sys file. No biggie, but a puzzler for a few minutes. 4) All my wonderful statistics don't work anymore. Oh well. Time to do some code hacking to get some semblance of information back in the log files, and some tweaking on the statistics code I used to use. I am quite impressed, however, with: 1) Speed. "C" news is gawd-awful fast. And I _LIKE_ that. We actually have our machine back during things like expire and unbatch. Nice. 2) The ability to junk a newsgroup without storing it. I don't know if "B" could do this, but if it could I never saw it in the docs. It works great with "C" news.... and has made me more than a little happy. 3) Policy decisions are made in shell scripts -- which means I can change them without having to recompile code. This is a major plus. 4) The batcher looks like it could be set up to handle our AKCSNet conferences as a batched feed -- which would make some of our neighbor sites which prefer to receive newsgroups as AKCS conferences very happy (previously we had to create and import them here, as "B" news couldn't handle creating batches while passing them through some other program easily). That appears to be solved with "C" news. The specifics have to be worked out here first.... and the doc problems mean that people who aren't familiar with Usenet and software configuration probably won't even ATTEMPT to run "C" news. A pity, as "C" news looks like a winner overall. >I agree about cnews expire being nice - I use it with B news (thanks to some >patches that were posted quite awhile back) to make the fastest system I've >tried (I haven't been able to try TMNN). TMNN is supposed to be killer-fast, but unfortunately it breaks EVERYTHING. I tried it out and quickly discarded it -- it had problems when we checked it out in the feed process, and utterly scrambled "rn"... We're staying with "C", although I did keep the "B" release around until I was darn sure that "C" was going to work out. One word of warning -- I had "B" news set up such that it would deal with VERY tight disk space. "C" doesn't seem to be able to get that fine-grained control that I liked with the B2.11.17 release I was using here (admittedly with some heavy hacks in the batching code!) Then again, disk space isn't as tight as it used to be here, so that doesn't look like it will be a problem. This will only be of concern to those sites that regularly get below 10kblocks in their spool areas..... -- Karl Denninger (karl@ddsw1.MCS.COM, !ddsw1!karl) Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"