john@jwt.UUCP (John Temples) (09/25/89)
I just applied patches 15 through 18 to my news software hoping that a problem would be fixed; but instead, another was introduced. The original problem has to do with the following line from my sys file: uniwdw:oau,comp.os.minix,comp.unix.xenix,to.uniwdw:F: 2.11.14 and 2.11.18 news will only batch up one or two random articles a week to this site. Why? The new problem introduced with 2.11.18 has to do with the speed of news unbatching. It's now taking 2-3 times as long to unbatch news. Under 2.11.14, my disk lights would stay on continuously until unbatching was done. Now, it looks like it's unbatching an article, sleeping three or four seconds, then doing another article. Has anyone else noticed this? -- John Temples -- UUCP: uunet!jwt!john
tneff@bfmny0.UU.NET (Tom Neff) (09/25/89)
In article <366@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >The new problem introduced with 2.11.18 has to do with the speed of >news unbatching. It's now taking 2-3 times as long to unbatch news. >Under 2.11.14, my disk lights would stay on continuously until >unbatching was done. Now, it looks like it's unbatching an article, >sleeping three or four seconds, then doing another article. Has anyone >else noticed this? I have seen somewhat lengthy processing times, seemingly dependent on the *length* of the articles being fed to rnews. For instance the recent "Elk" 14-part source in comp.sources.misc (I don't know about the rest of you, but an 800k Scheme interpreter is exactly what *I* was looking for!) took an agonizingly long time to spool each article. (It wasn't the uncompress either -- that only takes a couple of seconds for 30k->60k.) I assume we're checking for something now, but I'm not sure. -- "Take off your engineering hat | "The filter has | Tom Neff and put on your management hat." | discreting sources." | tneff@bfmny0.UU.NET
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (09/25/89)
john@jwt.uucp writes:
uniwdw:oau,comp.os.minix,comp.unix.xenix,to.uniwdw:F:
2.11.14 and 2.11.18 news will only batch up one or two random articles
a week to this site. Why?
Add "world," to the beginning of the distributions you send this site.
I find that TFM ("USENET Version B Installation") doesn't actually
document this properly, although every single example sys line does
include the "world" qualifier.
--Karlrick@uunet.UU.NET (Rick Adams) (09/27/89)
> Add "world," to the beginning of the distributions you send this site. > I find that TFM ("USENET Version B Installation") doesn't actually > document this properly, although every single example sys line does > include the "world" qualifier. From install.mn: 7.7. Distributions News 2.11 is much more particular about handling distribu- tions than previous versions. In particular, make sure that you have the distribution world in every line of your sys file unless you are specifically limiting the distribution and are sure you know what you are doing. That's pretty clear to me.
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (09/27/89)
rick@uunet.uu.net writes: | From install.mn: | tions than previous versions. In particular, make sure that you | have the distribution world in every line of your sys file unless That's what I get for just grep'ing "world" out the post-nroff file. It's _u_n_d_e_r_l_i_n_e_d so the grep didn't catch it. --Karl
clewis@ecicrl.UUCP (10/06/89)
In article <14728@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >I have seen somewhat lengthy processing times, seemingly dependent >on the *length* of the articles being fed to rnews. For instance >the recent "Elk" 14-part source in comp.sources.misc >took an agonizingly long time to spool >each article. (It wasn't the uncompress either -- that only takes >a couple of seconds for 30k->60k.) I assume we're checking for >something now, but I'm not sure. I'm seeing some rather frightening CPU times on the rnews that's unpacking individual articles. Like >1.20 CPU *minutes* on *one* 38K map article. A 3b1 isn't exactly a screamer, but >1.20 CPU minutes for a single article is more than a little extreme. Small articles go thru relatively quickly. (I upgraded from 2.11.14 to 2.11.18 too. Seems to work reasonably well other than this problem. I'm System V, so I'm using the 10 sub-history files under history.d, but that shouldn't be the cause of the problem, for I was running that before....) -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Phone: (416)-294-9253