My new system

[NEOAethyr]

TGM, DIODE lol .

Not thermistor .

 

Doide doide doide.

Though the ? has been answered, if there is no thermistor, then you're going by diode.

 

 

Edit:

Note to anyone.

Somewhat unstable means slower, even if it's benchign faster in some areas, there's gonna be other areas that it's slower.

A good example, superpi, you may get a few secs more or what not if the memory is'nt up to the task.

However, superpi does a very very good job at breaking in memory.

So..., a few passes on 1m, thena pass of 32m, this will get you that decent amount of speed if it can be broke in, and if it can even run those pi's.

 

Watch your times drop if such an accurance happens.

I noticed it long ago in everest, only so slightly, bandwith wise.

In superpi the diff can be a few secs, in front of your face results .

 

Remember to give windows a few to seddle down before running it.

Running it afew times may be key.

What I do, when benching the diff between ns, with a 0.01ns grainility, I pay attention to the initial value and 1st loop timings on 1m.

I repeat the test many times, writing down the min and max values for those 1st 2 parts of the test.

Works extremely well for those timings that are extremely hard to figuer out.

But you have to be runing slow enough otherwise there will be no diff, at least in my case it's that way.

So I run single chan, which is enough slow down to show diff's in timings at 280.

 

However if I tighten down on the bus timings, the alpha's, that diff goes away...

Still, there is room for testing on my end when needed.

 

 

Another edit:

6c diff in diode peak temps...

That's not that much, sorry to bring this up as ref but....

 

 

I aggree whole heatedly though cpu speed is what superpi needs after a certain amount of bandwith, abiet by timings(latency....) or mhz, or the 2, whatever.

 

I got those results when running 32m alot.

I noticed it was not memory timings that made my times better, matter of fact, I can run some timings, that are'nt stable, but good enough to get the same exact times or at least the 1st few loops/or maybe worse.

Etc.

However I up by one mhz fsb, which in turn up's the cpu by a tiny amount, and my times get better.

I probably would'nt say anything about it if I had'nt seen it enough.

 

 

Oh one more edit, dejavu....

Anyways comparing directly agains'nt 275x8 dc, and 250x10 dc, same exact timings.

The 250 blows it out of the water, no compare.

Even though 250 with the same timings as my 275 setup is not enough for superpi's peak, it still blows 275 away on superpi.

[TheGeekMistress]

There are varying degrees of unstable... can't run superpi... can't run 29089257083027 hours of 2347523490527390 prime and can't boot. This gave a single superpi error before running it three time in a row without a hitch... the unstable one took about 5 tries to get ONE run through. As a good scientist, I actively noted any variances/complications in the test procedure to help ensure it's validity. That being said, the numbers adhered largely to the trends already in place in that point so I felt it good to include the numbers with said note.

 

Now stop being a wankery philosopher about something as trivial as describing a memory setting as semistable or stable and look at the numbers involved.

 

 

 

This is stuff I already know. I was referring to the corrolation between whatever variable and the output superpi time. It is uncontested that CPU speed is king of superpi hill and was not the issue here. You'd do well to note that the most direct parallel in question is between the bandwidth and the superpi time... not MHz or timings or command rates. It also appears that MHz is closely behind bandwidth in the superpi time importance. It appears that timings/command rate are a far far distant third.

 

The bold part is totally wrong. Your super pi times go down because your processor is processing faster... period.

i agree, your superPI times go down with increased cpu frequency.

 

i really don't understand how you think of timings, mem bus frequency, and memory controller + core frequency. but they way i go is the highest bus i can go, then tweak the timings for low lats and adjust the mem bus down a bit for lowered lats... then the only thing left is increasing the core frequency. thats it.

 

my system, the faster the cpu, the higher the mem bus and the tighter the timings is what got me 29s.... i can't say anything more, i'll just let the score speak for itself.

 

TGM

[learners permit]

@ Sorrento. Man some of the cars I work on have 8 onboard computers tied together with a serial databus.

[Thraxz]

i agree, your superPI times go down with increased cpu frequency.

 

i really don't understand how you think of timings, mem bus frequency, and memory controller + core frequency. but they way i go is the highest bus i can go, then tweak the timings for low lats and adjust the mem bus down a bit for lowered lats... then the only thing left is increasing the core frequency. thats it.

 

my system, the faster the cpu, the higher the mem bus and the tighter the timings is what got me 29s.... i can't say anything more, i'll just let the score speak for itself.

 

TGM

 

You're being somewhat dense. The memory controller being faster is not what makes your superpi times go down. The processor speed being faster is what makes it go down. Of course tighter timings make your times go down... it increases bandwidth... of course the higher DDR rate made it go faster... it also contributes to higher bandwidth. Naturally, bandwidth becomes the most valuable stat on the ram because of this. It basically says you should optimize your ram to pull the highest bandwidth possible.

 

Futhermore, my data suggests to me that were I to consider higher MHz to take precedence over tight timings provided that 1T is kept I will find lower times on superpi. I'll run the test and get back to you and see if I'm right.

[red930]

You're being somewhat dense. The memory controller being faster is not what makes your superpi times go down. The processor speed being faster is what makes it go down. Of course tighter timings make your times go down... it increases bandwidth... of course the higher DDR rate made it go faster... it also contributes to higher bandwidth. Naturally, bandwidth becomes the most valuable stat on the ram because of this. It basically says you should optimize your ram to pull the highest bandwidth possible.

 

Futhermore, my data suggests to me that were I to consider higher MHz to take precedence over tight timings provided that 1T is kept I will find lower times on superpi. I'll run the test and get back to you and see if I'm right.

Come-on now, I know you have a better sense of sensibility than posting vulgar comments. Think man, think.

 

Wording your response in a respectfull, intelligent manner comes across much better than what you displayed. -AceGoober

[TheGeekMistress]

You're being somewhat dense. The memory controller being faster is not what makes your superpi times go down. The processor speed being faster is what makes it go down. Of course tighter timings make your times go down... it increases bandwidth... of course the higher DDR rate made it go faster... it also contributes to higher bandwidth. Naturally, bandwidth becomes the most valuable stat on the ram because of this. It basically says you should optimize your ram to pull the highest bandwidth possible.

 

Futhermore, my data suggests to me that were I to consider higher MHz to take precedence over tight timings provided that 1T is kept I will find lower times on superpi. I'll run the test and get back to you and see if I'm right.

i'm not being dense at all. why do you think we overclocked our FSB on the traditional NB/SB platforms. to increase the memory controller frequency. we already had dividers to run the ram faster and multi's to run the cpu faster.... but when the NB frequency is left behind, the system felts choked. that's because the memory controller running the bottleneck.

 

it's the same thing when the L2 cache was on the mobo running at the same speed as the FSB and increasing the cpu frequency eventually gave lesser returns in perfromance. then Intel made the Slot1 with the L2 on the board next to the cpu and it ran at half the speed of the cpu, then they made the PIII with the L2 "on die" and it ran the same frequency as the core and it took out the bottleneck.

 

the frequency perfromance of the memory controller effects perfromance just as the frequency of the cpu other wise we'd never of gotten into overclocking the FSB in the NB/SB platform.

 

but, if you think you're right...

 

TGM

[Sorrento]

@ Sorrento. Man some of the cars I work on have 8 onboard computers tied together with a serial databus.

And if you know a little about Formula 1 you know the mega super duper systems controlling the hydraulic system, which pretty much control everything in the engine, gear box and brakes. AMD is partner with Ferrari while Intel is with Toyota... lol, yet these aren't the top teams

 

 

 

 

 

 

 

 

 

GUYS, you are way wrong about everything regarding SuperPi... and I would think twice before starting to insult other members of the forum regarding the information you think you know about this tinny test.

 

Of course Memory performance (type of chips, latencies, etc) and thus memory controller have a great part in the SuperPi result... this between processors with equal speeds and regardless of brand or socket.

 

Intel Prescott 3.0E @ 4.1 ghz with BH5 modules at 2 2 2 5 would score 1 second higher than same system at same speed with TCCD 2 2 2 5 RAM... and one second was like 140 megaherts at those superpi times.

 

 

/Edit

 

Btw, thanks Ace...

[-aDaM^]

Lookin real good but its a shame you went with a watercooling KIT, DIY gives much more performance.

[Thraxz]

That was a problem on my old Intel system. The memory bandwidth was bottle necked by the miserable FSB DATA TRANSFER RATE of the Intel system when running ddr 500 dividers at STOCK FSB speeds. Basically, the FSB was unable to transmit information as fast as the memory could provide it. That has little relevancy to what you are describing with the memory controller.

 

Intel Prescott 3.0E @ 4.1 ghz with BH5 modules at 2 2 2 5 would score 1 second higher than same system at same speed with TCCD 2 2 2 5 RAM... and one second was like 140 megaherts at those superpi times.

 

Also irrelevant... I was not comparing one module to another. I am saying all else being equal, bandwidth wins superpi runs. Until you can provide evidence to the contrary I'm taking the upper hand here.

[Sorrento]

Uhh, RAM was running at the same speed both times... either at DDR400 or the next divider, I forgot the ram speed, using a lesser divider.

 

Same latencies, same ram speed... but 1 second diference because of the BH5's... do you think RAM performance has little to do with superpi results? The BH5 is a set of Mushkin Level II PC3500 and the TDDC is a set of Platinum Rev2 DDR400.

[Thraxz]

All things are not equal are they, if the system has two different modules?

 

And yes, you are most likely correct about the BH-5 being slower than the TCCD. Too bad it isn't relevant to what we are discussing.

[TheGeekMistress]

Lookin real good but its a shame you went with a watercooling KIT, DIY gives much more performance.

yah, i have been leaning on the regret side of the arugment. i should have just built another DIY system, but i just wanted a decent water cooling system so i didn't have to piece and part around for things.

 

only thing i'm stumped on is the overclock difference between the first NF3 mobo of 3200mhz and this NF3 mobo i have now that only does 3080mhz.

 

i've got a few things left to try out yet, so i'm not done with it yet.

 

TGM