Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!uc!cs.umn.edu!thelake!steve From: steve@thelake.mn.org (Steve Yelvington) Newsgroups: comp.sys.atari.st Subject: Re: Re: Full UUCP implementation for the ST? Message-ID: Date: 20 Jul 90 07:33:58 GMT References: <19896.26a3ddf7@oregon.uoregon.edu> <1990Jul19.173152.1647@murdoch.acc.Virginia.EDU> Organization: Otter Lake Leisure Society Lines: 55 X-Member-Of: STdNET [In article <1990Jul19.173152.1647@murdoch.acc.Virginia.EDU>, gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) writes ... ] > In article steve@thelake.mn.org (Steve Yelvington) writes: > >>I wrote an rnews program for UUMAIL that unbatched news and wrote >>single files to a spool directory. It worked well but slowly -- GEMDOS >>is miserably slow in creating new files on a drive that's >>three-quarters full. (In my experience, all disk drives are >>three-quarters full, except the ones that are completely full.) > > This is a known and fixed problem in TOS 1.0 and TOS 1.2 that has been > discussed here repeatedly. Just like MS-DOS 2.XX, these tos versions > pick a new cluster by searching from the start of the FAT, every time. > When your drive is mostly full, this takes quite a while. TOS 1.4 has > a next-fit algorithm instead, which starts from the last cluster it > allocated. > > If you are running 1.0 or 1.2, you can use FATSPEED to fix this > problem. FATSPEED also accellerates finding the number of free bytes > on a drive. I have been using FATSPEED for several years and it seems > very reliable. Yeah, I'm still stuck back in the dark ages with TOS 1.0. I heartily recommend FATSPEED -- along with a few other programs such as PINHEAD (or NULLFILL) and a disk cache, it helps make TOS a lot less painful. Even with that help, though, we found that creating new files involved significant overhead, especially when the directories got big (sometimes 300 or 400 files) and the drive got fragmented. Unbatching large quantities of Usenet news was taking more time than receiving it at 1200bps. If the ST were a multitasking system it wouldn't have been such a problem, but it's not -- and having to wait 45 minutes while the machine processes news isn't my idea of fun. Ditching the whole idea of "one message, one file" was just one of the speed enhancements. We also pull an entire Usenet message into RAM before processing it. The header is scanned using pointers and offsets; the "Path:" line is examined and updated; the "Message-ID:" line is extracted for comparison with a history file, and the "Newsgroups:" line is extracted for delivery and forwarding purposes. Disk writes then take place using single Fwrite() calls. Dale Schumacher's most recent speed enhancement is crunching the message-IDs to a 32-bit CRC, which allows a simple comparison of long integers to replace a function call to strcmp() and also cuts the RAM usage. This rnews is about as fast as it can get. -- Steve Yelvington at the lake in Minnesota steve@thelake.mn.org