dr@myrias.com (Dragos Ruiu) (07/25/89)
In article <1989Jul16.000620.10241@tarpit.uucp> rd@tarpit.UUCP (Bob Thrush) writes: > > I have been running C News since July 5. I am extremely >impressed with the increase in performance and *much* easier >administration. With B News 2.11.14 and dbz, this system was >processing about 12 articles/minute. It is now achieving about >28 articles/minute. Many thanks to Henry and Geoff for an >important improvement to news software! > 28 articles/sec !!! Gak. I'm getting >100/sec on my uPort 2.4 system. (using dbz) Some suggestions: - Get the compress sources, and fudge a version of compress that only uses 12 bits. Compile in small model. This is a major speed win. (Just define PCXT in the sources and remove the microport specific patches if you have applied them.) - Compile news in the small model. Small model programs work MUCH faster. It seems to work fine in the small model. >Bob Thrush UUCP: {ucf-cs,rtmvax}!tarpit!rd >Automation Intelligence, 1200 W. Colonial Drive, Orlando, Florida 32804 -- Dragos Ruiu What do you get when you cross a grape with an elephant ? myrias!dr Grape Elephant Sine Theta
rd@tarpit.uucp (Bob Thrush) (07/27/89)
In article <617322137.22632@myrias.com> dr@myrias.com (Dragos Ruiu) writes: >In article <1989Jul16.000620.10241@tarpit.uucp> rd@tarpit.UUCP (Bob Thrush) writes: >> [ ... ] With B News 2.11.14 and dbz, this system was >>processing about 12 articles/minute. It is now achieving about >>28 articles/minute. Many thanks to Henry and Geoff for an >>important improvement to news software! > 28 articles/sec !!! Gak. I'm getting >100/sec on my uPort 2.4 system. (using >dbz) 28 articles/minute (or < .5 article/second) compared to >100/sec ... Hmm... Sounds like tarpit is at least 200x slower than your machine. Are you sure about your nos? :-) I just rechecked the numbers today. 2392 articles in 4123 seconds which works out to ~34 articles/minute (not per second!). The 2392 articles were obtained via `wc -l /usr/local/lib/news/log'. The times were obtained by adding up differences between the stop and start times for the newsrun entries in /usr/lib/cron/log. > Some suggestions: > > - Get the compress sources, and fudge a version of compress that only > uses 12 bits. Compile in small model. This is a major speed win. > (Just define PCXT in the sources and remove the microport > specific patches if you have applied them.) I have been running the small optimized -Dpcxt compress this way since last fall. You're right about the speed win. In the past, I had cobbled up rnews (B News version) to do something like newsrun thereby allowing the performance win but also safely accepting 16-bit compressed batches. (I have inserted my special 12 bit compress ahead of the normal compress in newsrun.) I would like to see an even faster version of compress. > - Compile news in the small model. Small model programs work MUCH > faster. It seems to work fine in the small model. In my first (and so far only) attempt in small model, I had problems with expire (mentioned in <1989Jul16.000620.10241@tarpit.uucp> which Henry correctly diagnosed as SMALLMEM not being defined. Do you suppose it's the large model that's keeping me from getting 100 articles/second? :-) Your point about the small model is well taken. When I incorporate the July 23rd patches, I will definitely go with the small model. >-- >Dragos Ruiu What do you get when you cross a grape with an elephant ? >myrias!dr Grape Elephant Sine Theta -- Bob Thrush UUCP: uunet!tarpit!rd Automation Intelligence, 1200 W. Colonial Drive, Orlando, Florida 32804
henry@utzoo.uucp (Henry Spencer) (08/04/89)
In article <617322137.22632@myrias.com> dr@myrias.com (Dragos Ruiu) writes: > - Compile news in the small model. Small model programs work MUCH > faster. It seems to work fine in the small model. Some things may be a bit tight for space, since we haven't had a 16-bit machine on hand for testing since utzoo transmuted itself into a Sun, but everything in C News is thought to work in a 16-bit address space. A number of people, both on pdp11s and on Intel machines, have reported success (the smaller buffer in expire that showed up in one of our patches was the result of some of their experience). Note that you will need to tell "build" about it -- a number of things are more byte-thrifty when they know that space is tight. -- 1961-1969: 8 years of Apollo. | Henry Spencer at U of Toronto Zoology 1969-1989: 20 years of nothing.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu