dean@coplex.uucp (Dean Brooks) (01/24/91)
I have just installed C-News at our site, and am very impressed
with the speed of unbatching and versatility.
However, I am curious, do people generally regard C-News (as of the
Dec-15th patch) as being completely reliable for news transmission?
We have several sites who consider reliability as a number one factor,
and I was curious of other peoples opinion.
Installation was fairly straightforward, except for some problems
with permissions conflicts with the build script. But it concerns me
that there are so many shell scripts used instead of binaries. Scripts
are nice, but there are some things (ala postnews) that seem a little
too complex for script use.
Anyone had any problems with the scripts? Also, I like the methods
of checking free space, but I was curious how well recovery is taken
care of when space becomes too low (unbatching, etc).
--
dean@coplex.UUCP Dean A. Brooks
Copper Electronics, Inc.
Louisville, Ky
UUCP: !uunet!coplex!deankaul@icarus.eng.ohio-state.edu (Rich Kaul) (01/24/91)
In article <1991Jan24.014403.1255@coplex.uucp> dean@coplex.uucp (Dean Brooks) writes:
I have just installed C-News at our site, and am very impressed
with the speed of unbatching and versatility.
Yes, C-news is very quick. I used Dave Alden's relaynews patches
(turns it into a daemon) and Paul Vixie's msgid daemon to manage news
load. Both are available from shape.mps.ohio-state.edu. It really
helps when you have two big, fast sites feeding you news constantly.
Our CPU usage for news has dropped to less than 10% of what it was
under B-News. I'm very impressed.
However, I am curious, do people generally regard C-News (as of the
Dec-15th patch) as being completely reliable for news transmission?
I haven't seen any problems, and I keep some very complete statistics
on what goes through here.
Scripts
are nice, but there are some things (ala postnews) that seem a little
too complex for script use.
Then use the B-news postnews if you like. There's nothing to keep you
from mixing and matching. I've been pleasantly surprised at all the
shell scripts -- makes for quick and easy modifications to many
functions. If you want speed and more portability, rewrite them in
perl. I've done some minor additions for our site and have written
them in perl.
--
Rich Kaul | Every man is given the key to the door
kaul@icarus.eng.ohio-state.edu | of heaven; unfortunately, the same key
or ...!osu-cis!kaul | opens the door to hell.clewis@ferret.ocunix.on.ca (Chris Lewis) (01/25/91)
In article <1991Jan24.014403.1255@coplex.uucp> dean@coplex.uucp (Dean Brooks) writes: > However, I am curious, do people generally regard C-News (as of the >Dec-15th patch) as being completely reliable for news transmission? It's completely reliable modulo a few caveats. See below... >But it concerns me >that there are so many shell scripts used instead of binaries. Scripts >are nice, but there are some things (ala postnews) that seem a little >too complex for script use. There's nothing unreliable about scripts per-se. No worse than compiled programs. Provided they're written well (and C-new's are). > Anyone had any problems with the scripts? Also, I like the methods >of checking free space, but I was curious how well recovery is taken >care of when space becomes too low (unbatching, etc). C-news is perfectly reliable as long as: 1) all of the throttles work, both incoming, spooling and news control areas. Test 'em. 2) the throttles are set "reasonably" 3) You don't routinely run close to the edge 4) You pay attention to what C-new's admin scripts tell you. Some suggestions: 1) If at all possible, get the news spool area OFF of the partition that has UUCP queues. Eg: /usr/spool/news and /usr/spool/uucp are different partitions. This decouples incoming throttles from outgoing ones, otherwise, the throttles can sometimes go into something that looks like positive feedback and your disk space goes up and down like a yoyo, or your incoming feed bogs down or starts tossing articles. You want to make sure that even if a big flood comes in, it doesn't bog down your outflow. If it does, you're screwed. 2) You should occasionally check to ensure that your spool areas are above the thresholds. Under certain circumstances, the incoming throttle can stall out the incoming feed indefinately. Which really can get you into trouble. 3) Write a cron script to kill incoming feed's uucico sessions and temporarily "Never" that site's Systems/L.sys entries, if the disk space falls below some threshold. This should be above the unpacking threshold. Maybe Jim Mercer at lsuc would publish "spoolfull" as a starting point. (I wrote much of it, but it is "his" machine) 4) If you're getting a high volume feed, you MUST keep up. Otherwise, your feed will start expiring articles before they're batched to you, and you'll never catch up again. (without intervention). About a week ago I unstuck one system that was over a week behind. Needed several expires (that almost rm -fr's). Never saw so many news articles go thru so fast in my life... 5) Running expire more than once per day is often good if you have high thru-put but short retention times. You want news flowing as much as possible. 6) outgoing stuff: keep the queue sizes *down*, but at the same time, up the sendbatch call times to a point where if a site has fallen behind, if it connects, sendbatch will be called frequently enough to keep the line busy until everything's sent. This is a compromise, because sendbatch can sometimes be a real hog. The one thing stock C news can't do is stop other sites from giving you batches. If you hit the unpacking threshold, news articles will stay on your machine for longer than they should (they don't get unpacked to be candidates for outgoing or expiry) and you'll probably start tossing batches. As mentioned in (3) there are programs to solve this. There are other tools available, such as rnews.c which I believe can do progressive expires if you're short of space, and have faster (but less portable) ways of doing spacefor. There are other tools to treat other partitions on your disk as "shock absorbers" for incoming stuff. As long as you stay away from the thresholds, you shouldn't need these things. Bnews, on the other hand, is a little less sophisticated in some of the throttles. Bnews, particularly older ones, had a tendency to fill disks, then expire would clear some space, and Bnews would stagger on. Possibly with corrupt history files and lost articles which you don't get to know about. The latest version (PL19) is pretty good. -- Chris Lewis, Phone: (613) 832-0541, Internet: clewis@ferret.ocunix.on.ca UUCP: uunet!mitel!cunews!latour!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Psroff enquiries: psroff-request@eci386, current patchlevel is *7*.
henry@zoo.toronto.edu (Henry Spencer) (01/27/91)
In article <1991Jan24.014403.1255@coplex.uucp> dean@coplex.uucp (Dean Brooks) writes: > However, I am curious, do people generally regard C-News (as of the >Dec-15th patch) as being completely reliable for news transmission? Geoff and I do not qualify as exactly unbiased :-), but reliability is probably our #1 concern. C News work is not, to any great extent, what we get paid for. News failures almost by definition interrupt work normally considered more important. The biggest concern for most any such software on our systems is that it run smoothly and not bother us. C News was designed to behave itself unattended. Admittedly, our experience is not necessarily typical because we're really used to the software... but our experience is that, with the single caveat that you must not be too desperately short on disk space, it does behave. We have had fan mail from others to this effect -- e.g. "needs much less handholding than B News" -- but it is hard to assess how representative it is. With well over 1000 sites running C News, however, any major reliability problems should be inundating our mailbox with complaints. That has not happened. Startup problems happen, but the rare cases of sustained difficulties seem to be local problems like strange systems. C News does try to react well to space shortages, but its safety margins can't be trimmed to zero, and if things get too tight it will end up backed into a corner where it can't *do* anything for fear of overflow. Utzoo ran with a modest disk shortage for some time, and C News coped in day-to-day operations, but it was a constant nuisance making sure that enough space to break any logjams did eventually become available. -- If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (01/27/91)
>C News does try to react well to space shortages, but its safety margins >can't be trimmed to zero, and if things get too tight it will end up >backed into a corner where it can't *do* anything for fear of overflow. >Utzoo ran with a modest disk shortage for some time, and C News coped >in day-to-day operations, but it was a constant nuisance making sure >that enough space to break any logjams did eventually become available. I agree that C News is pretty maintenance free except for disk space problems. There are various C News add ons that cure this problem (and have a few other benefits). My favorite is available via ftp from ais.org in /pub/news/cnews.speedups.Z -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us