Date: Tue, 10 Jun 1997 09:56:15 -0700 (PDT) From: Tom <tom@uniserve.com> To: "Michael L. VanLoon -- HeadCandy.com" <michaelv@MindBender.serv.net> Cc: Satoshi Asami <asami@cs.berkeley.edu>, burton@bsampley.vip.best.com, current@freebsd.org Subject: Re: overclocking Message-ID: <Pine.BSF.3.96.970610092838.23362A-100000@shell.uniserve.com> In-Reply-To: <199706101358.GAA17309@MindBender.serv.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Jun 1997, Michael L. VanLoon -- HeadCandy.com wrote: Another point, I forgot to mention: Satoshi has experience with very large drive arrays. So what he says is based on experience. Not many have built and used 20GB+ arrays under FreeBSD. > > A couple of issues: > >- The best quality drives are 7200rpm only > > How does quality equate with rotational spin? Actually, 7200RPM > drives are much more likely to melt down if you don't cool them well. > Which would make 5400RPM drives, on the average, more reliable. Nothing. But if you buy a new high quality drive, it will be 7200rpm. I don't even know where I would get a 5400rpm drive from. Perhaps Seagate is still making the Hawk series, but I was never impressed with the Hawk quality. New 7200rpm drives run much cooler than ever, and now have mtbf's much longer than most 5400rpm drives. > >- Striping two 7200rpm drives is even better than striping two 5400rpm > >drives > > This is true. It's also a lot more expensive. > > >- Putting /usr/src and /usr/obj on separate drives is probably better than > >stripping, because you know that accesses will happen in parallel. But > >again, this is optimization specific to world building, not general-use > >systems. > > Putting /usr/src and /usr/obj on separate striped ccd partitions would > be even faster. :-) Sure, but now you are up to at least 4 drives too. > >- Striping is not going to improve seek performance > > Sure it can. Especially with tagged-command-queuing. You have > multiple mechanisms seeking simultaneously. That would be faster than > trying to move all the data through one set of heads, which can only > be at one location at any single point in time. Yes, but it not going to improve the time for a single seek. The multiple mechanisms can only seek in parallel, if there is multiple things to do, but many types of tasks have to be run in serial, because each step depends on the previous. For example, a compiler. > > As far as Joe Greco goes, he has been huge proponent of using large > >numbers of 5400rpm, but that's his opinion. I prefer fewer, but faster > >drives. I don't believe Joe has ever tried building a system with mostly > >7200rpm drives. Anyways, I get a newsfeed from Joe, and provide some > >charity feeds to some ISPs... > > > > Anyways, I won't get anything but 7200rpm drives these days, but I also > >need all the performance I can get. > > I'm glad you can afford all those 7200RPM drives. :-) I'm glad you can afford all those 5400rpm drives. But considering the reliability of the older 5400rpm drives, and the space required to hold double the number of drives, it just isn't worth it. Plus, more drives is more chance of failure. > However, a question you might ponder: are you faster with a few > 7200RPM drives in a ccd than you would be if you spent that money on > two or three extra 5400RPM drives and made your ccd consist of more > drives? You also have to look at housing and power costs. I build systems for machine room environments. Space is very costly. > I'll bet there's an interesting trade-off there. > > ----------------------------------------------------------------------------- > Michael L. VanLoon michaelv@MindBender.serv.net > --< Free your mind and your machine -- NetBSD free un*x >-- > NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, > Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... > NetBSD ports in progress: PICA, others... > ----------------------------------------------------------------------------- > Tom
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970610092838.23362A-100000>