Date: Fri, 6 Aug 1999 22:15:05 -0700 (PDT) From: Brian McGroarty <bvmcg@yahoo.com> To: Julian Elischer <julian@whistle.com>, Brian McGroarty <BMCGROARTY@high-voltage.com> Cc: freebsd-hardware@FreeBSD.ORG Subject: Re: The $500 Performance Question Message-ID: <19990807051505.3696.rocketmail@web1003.mail.yahoo.com>
next in thread | raw e-mail | index | archive | help
Moving from the old wd driver to the new ata made very, very little difference. Soft updates shaved about 10 minutes off the build however. I don't believe more RAM will buy me anything as I'm already at 512 and I don't think the free section dips under 200 during make world. I'm not sure I see where building objects to another drive would help either with lazy writes/soft updates on since the entire block of files to be written easily fits within RAM. I'm also of the opinion that reading ahead in the make file won't make a tremendous difference if I'm using "make -j 40 world" as there should most always be a task ready to run while the read operation waits to complete on a stalled thread. Interestingly, despite there only being a (roughly) 15% decrease in time, CPU usage jumps tremendously. Most of the time I'm averaging about 20% free on one CPU and as little as 5% on the other. I'll be curious to look at the soft update code - I wonder if that's coded as efficiently as it could be. --- Julian Elischer <julian@whistle.com> wrote: > ensure that all output is to different drives and a different > controller > from the source. use soft updates, (or async if the output > drive is > expendable). use -current. possibly modify each makefile at a > medium > level to preread the sources so they are in cache (and use the > money to > add more RAM). The disks should be DMA and the trick is to > make sure that > everything is already in RAM. > > On Fri, 6 Aug 1999, Brian McGroarty wrote: > > > I've got a PC used primarily for programming. Projects tend > to be large (8-12 > > megs of C++ source), so build time is a concern. I'd like > ideas on where the > > best place to sink $500 would be to boost performance. > > > > Relevant in the current configuration: > > > > o (2) Celeron 300a (on socket converters, overclocked to > 500mhz) > > o Tyan Tiger 100 motherboard (Dual CPU) > > o 512mb 100mhz RAM > > > > EIDE controller: > > o 14 gig 7200 EIDE (/usr,/,swap) > > o 28 gig 7200 EIDE (/tobackup,/cvs) > > > > EIDE controller 1: > > o 14 gig 7200 EIDE (/home) > > o 2/8x CDRW/CD-ROM > > > > For a familiar benchmark, a FreeBSD 'make world -j 40' takes > about an hour > > and ten minutes. This may be slewed against your ssytem by > the inclusion of > > -O3 optimization. > > > > The CPUs realize a lot of idle time; upward of 60%. I expect > then that I/O is > > my main bottleneck. > > > > The drives are Ultra-66 capable, but I don't believe FreeBSD > supports this at > > current. Thus, I don't see a way to enhance what I've got. > (I'm already > > enabling 32-bit and DMA on the controllers via flags). > > > > So what's my best bet? Is there a fast and economical SCSI-2 > controller and > > drive I should try? Any supported IDE RAID controllers? Or > is there an > > Ultra-66 controller FreeBSD merely sees as really fast EIDE? > > > > Or is this time being spent in the huge kernel lock? Would > CAS2 capable RAM > > then perhaps speed the buffer transfers noticably and get > the CPUs back to > > unmanaged portions more quickly? > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hardware" in the body of the > message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hardware" in the body of the message > > _____________________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990807051505.3696.rocketmail>