Skip site navigation (1)Skip section navigation (2)
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>