Date: Thu, 14 Dec 2000 03:11:42 -0800 From: Kent Stewart <kstewart@urx.com> To: Mike Meyer <mwm@mired.org> Cc: questions@freebsd.org Subject: Re: advice with old equipment. Message-ID: <3A38AAEE.56303833@urx.com> References: <14904.1150.593498.981432@guru.mired.org> <3A381379.9F464204@urx.com> <14904.20712.193427.889148@guru.mired.org> <3A3862E1.A0D6E0C2@urx.com> <14904.28164.273218.788343@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A38AAEE.56303833>