mclure@sri-unix (07/22/82)
For news 2.7, 2.8: uurec processes each of our incoming Usenet articles (we get our articles over the Arpanet from CCA). Each uurec takes about 1 minute of real-time and 15 seconds cpu, generally, on an unloaded 11/70. We're running the ittvax!swatt sequencer code, but the times above were similar before we inserted that code into gename.c in the uucp sources. My question is this. Has anyone else done timings on uurec/uux? It would seem a trivial task to insert the article in the proper location in the /usr/spool/news heirarchy, create the appropriate files in /usr/spool/uucp, etc. I can't understand why these seemingly minor tasks should consume so much time. Any news/uucp wizards out there willing to speculate? Stuart
swatt (07/23/82)
It may not be clear from the first few lines of my "gename.c", but if your system is not "ITTVAX" and you just compile gename.c without -DTSSEQ -DSEQHUNK=10, you will get exactly the same behavior as the original. This was perhaps a bit of overcaution on my part to make the old behavior the default. If you just use the -DTSSEQ flag, you will get base 62 sequence numbers, but (alas) still fetch them from the sequence file 1 at a time. An easy way to tell if the -DTSSEQ flag was in effect is: nm -g uux | grep _tstoa If the -DTSSEQ option is not defined, "tstoa()" is not compiled, in which case you can be sure the chunking option is not in effect. If the symbol is present, do: cat /usr/lib/uucp/SEQF uux foobaz!mumblefratz cat /usr/lib/uucp/SEQF which although uux will complain about unknown system "foobaz" will still force a "gename" call or two. By comparing the sequence file before and after you can tell what the chunk size is (NOTE: a normal uux call will generate ~6 "gename" calls). This is a rather long prelude to the totally unrelated conclusion that this is still not your problem, as uuxqt won't call "gename" unless an output file is specified; uurec doesn't call it at all; and uucico won't call it unless the "callback" flag is set in L.sys (or USERFILE, I forget which; for long and gory reasons, the callback feature just plain doesn't work anyway). Conclusion: if the "uurec" operation takes too long, look elsewhere than the UUCP system for the culprit. Previously Mark Horton (I think) has mentioned that if your news history file is large, inserting a new article will take a long time. Versions 2.8 (I think) and later of "expire" would correctly expire articles and re-write the history file to contain only those articles left in the system. I am not familiar with the uurec operation, so I really can't comment further. - Alan S. Watt (decvax!ittvax!swatt)