Date: Thu, 14 Dec 2000 11:27:57 GMT From: Cliff Sarginson <cliff@raggedclown.net> To: kstewart@urx.com, Mike Meyer <mwm@mired.org>, questions@FreeBSD.ORG Subject: Re: advice with old equipment. Message-ID: <E146WYH-0006VQ-00@post.mail.nl.demon.net>
next in thread | raw e-mail | index | archive | help
My pentium 166 is weeping ... :( January, then I buy a fast mother .. :) Tell me what to buy ! Cliff > > > Mike Meyer wrote: > > > > Kent Stewart <kstewart@urx.com> types: > > > Mike Meyer wrote: > > > > Salespeople love CPU clock speed - it gives them a single number to > > > > feed to consumers to make their product look good. The reality is > > > > *much* more complicated, though. My 400MHz PII/Xeon blows the doors > > > > off my 500MHz K6-2. But a 500MHz PIII w/512K of cache would outperform > > > > the Xeon - and the pricing on the chips reflects that. > > > I always thought a Xeon with 4MB of cache memory would be pretty > > > awesome in a server. > > > > I'm looking at upgrading my Xeons to 2MB - I haven't seen the 4MB > > version anywhere. Is it a PIII thing, or otherwise incredibly > > expensive? > > > > > > > A buildworld on the Celeron 433 is a little bit faster than a > > > > > buildworld on a Abit BX6 rev 2 with a P-II 400. The Abit board is > > > > > about 10% slower than a SuperMicro with the same speed cpu. Never have > > > > > figured that one out. > > > > What's the cache size on the two P II systems? 256K vs. 512K, maybe? > > > They are all 512k. I have been going to replace one of them with a > > > coppermine to see what that does. A number I read was that throughput > > > vs clock speed was linear up to about 3x the FSB. > > > > Interesting claim. Not sure I believe it, though. Of course, there may > > be some unstated assumptions (cache size and application load, for > > instance) that make it true. > > It is one of those trivia numbers that I have in my head. I would like > to know when it stops being linear but don't want to pay for the > knowledge :). > > > > > > At some point after that, the cpu was spending time waiting for data > > > and cache would really become important for some types of > > > computations. On my systems currently, it is a 1/2 speed, full size > > > cache on the P-II's/III's and a 1/4 size, full speed cache on the > > > Celeron 433a. I had a 300a that I overclocked to 450 until it > > > died. For about 2 months it out performed a P-III 450. It died from > > > overheating building XFree86 3.3.4 after one of the releases. A > > > trivia point is that adding PC-100 memory to the Celeron's speeded > > > them up about 15%. You can get back some of the 150% you lose > > > because of the cache and FSB. > > > > I thought the PIIIs had full speed caches. > > Only the Coppermines (?). They went to full speed cache when they > dropped the cache to 1/2 size. Before that they were 1/2 speed just > like the P-II's. > > > > > > I got interested in the AMD Athlon because of the additional pipelines > > > that the Intel Pentium's didn't have. I thought pipelines were > > > important on the old Cray and a good algorithim would help the PC. > > > > Pipelines were important on the old Crays. However, the important > > pipline was in the array processors, not the CPU. When they did array > > operations, the data from the input arrays were pipelined through the > > array processor so that you could do hundreds of flops at the rate of > > one per machine cycle. The CPU was pretty much RISC, which made all > > the instruction decode stuff fast. For something like an AMD, the work > > that led to the MIPS (IIRC, that's a machine *without* Interlock > > Pipeline Stages - the compiler was supposed to make sure the there > > were no bubbles in the pipeline, so the hardware didn't have to, and > > hence could run faster) might be more relevant. > > Ok, they got into that a little bit when you would attend one of their > performance courses. The first morning was all spent on understanding > your hardware. You really couldn't take advantage of the compiler and > the multiple cpu's until you understood some of those interactions but > they couldn't spend too much time on the hardware because someone else > was hired to cover that part. This is missing in the compilers we use. > Cray compilers with everything turned on were really slow. In 1988, I > think Lehey Fortran on a 486 25Mhz was just about the same speed on a > line count basis. We took one of our programs from the Cray and tried > to build it with Lehey on a system running NT. After 7 hours it was > only half way through. A week later we had Microsoft Power Fortran and > it did in two minutes what would have taken Lehey 14 hours. That > became DEC Fortran. Lehey wasn't really that slow it was the make > program that was doing it. It would fire up the compiler for each > module and that took time. It only takes one stupid bit being set for > the whole process to look dumb. DEC Fortran only loaded the compiler > once and then processed a list. That was MUCH faster even in a windows > environment. When I got on to FreeBSD almost two years ago, the other > Lehey spent a couple of days breaking me into doing Makefiles on > FreeBSD without a couple of stupid-bits set :). > > > > > > The > > > Athlon 900's are pretty fast. I have an old Micron Millennia P-200 > > > with 128MB of 60ns EDO. It is ~15.5 times slower doing a Seti workunit > > > (wu) than the Athlon 900 with 256MB of PC-133 memory. The times are on > > > the order of 277,xxx secs vs 17,8xx secs with a lot of variation on > > > both sides. It was a wu every 3+ days vs 4.8+/day. I will see what > > > they work out to be after a 100 or so. The Micron has been cranking > > > for 1.6 years and the Athlon is catching up fast. > > > > Hmm - that's close to linear with my Xeons, which are averaging around > > 37,4xx. Since the Athelon costs about half what a PIII does, that > > makes it a bargain for seti@home wu's. > > That is what I have been thinking. Of course, what I want is one of > the dual socket A's and a version of FreeBSD that will SMP it. I don't > think they have the mb's out beyond the design stage. The new DDR > memory and UltraWide 160 scsi might give me a machine that will do a > complete build world in 30 mins. You see all of these problems with > subjects of "BuildWorld Failures". There are a few that stand out > enough that they might be real. From a support point of view, it would > be really handy to be able sit here and when you see one of the > possibles pop up, fire off a simple script update that would do > everything from cvsup to installworld. My simple logging script > currently takes around 1840u seconds on the Athlon but needs a little > under 1.5 hours. That is a little bit slow and I'm working on what is > taking the other hour. With that kind of speed, you might even be able > to stand watching x-windows or KDE-2 build :). I think with a 30 > minute build and response times, you could provide an hour turn around > on build problems. > > Kent > > > > > <mike > > -- > > Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ > > Independent WWW/Unix/FreeBSD consultant, email for more information. > > -- > Kent Stewart > Richland, WA > > mailto:kbstew99@hotmail.com > http://kstewart.urx.com/kstewart/index.html > FreeBSD News http://daily.daemonnews.org/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E146WYH-0006VQ-00>