i7 / HT / GTX question

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6542
Credit: 287272542
RAC: 92964
Topic 194691

I couldn't find a better place so I have a few very "un" green questions :-)

I'm trying to push this rig for everything it can give.
Currently my i7-920 D0 is running 4.3 GHz at 3.75 vCore.
I was wondering if in general we can run higher clocks that say Prime95 Blend or WCG?
Does this project respond better to raw core GHZ increases or am I better off tweaking up my memory bandwidth & timings?
Does HT help or hurt in terms of throughput?
and just to finish of killing the greenies ... I am also running a GTX 295 full bore OC'd for GPUGrid in this PC but looking forward to the day when there is a GPU package that can fully utilize all my shaders here :-)

Crunching my ascii off,
Steve

I have made this letter longer than usual because I lack the time to make it shorter ...

... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6542
Credit: 287272542
RAC: 92964

i7 / HT / GTX question

It's perfectly OK to start a new thread with a new question, so I did that for you. :-)

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter ...

... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6542
Credit: 287272542
RAC: 92964

As for the questions, here's

As for the questions, here's my 2 cents ----> Well, it depends .... :-)

Quote:
Currently my i7-920 D0 is running 4.3 GHz at 3.75 vCore.


Nice one.

Quote:
Does this project respond better to raw core GHZ increases or am I better off tweaking up my memory bandwidth & timings?


Each ( gravitational wave ) unit of computation has more or less equal parts of memory bound and CPU bound code/time. So yes to both then.

Quote:
Does HT help or hurt in terms of throughput?


Many are less excited than we were about HT. Actual cores are better than virtual - there's always an overhead ( the tasking algorithm plus flipping in & out of task state segments ). I vaguely recall ( please correct ) that i7's do better with a mix of computation/application types.

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter ...

... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5850
Credit: 110127634033
RAC: 25341520

RE: Currently my i7-920 D0

Quote:
Currently my i7-920 D0 is running 4.3 GHz at 3.75 vCore.


I presume you mean 1.375 Vcore?

Quote:
I was wondering if in general we can run higher clocks that say Prime95 Blend or WCG?


My experience has been that the E@H apps tend to be quite hard on the CPU and I've seen examples of hosts that appear to be prime stable (or reported to be stable on other projects) that can develop errors when running E@H tasks. I regard prime stability as a good starting point from which to back off a bit so as to ensure no crunching errors. After all what is the point in saving a couple of minutes only to lose hours of crunching time if the occasional task starts failing well into the crunch cycle?

Quote:
Does this project respond better to raw core GHZ increases or am I better off tweaking up my memory bandwidth & timings?


I'm sure both have an effect but my experience is that raw CPU speed gives you a bigger gain.

Quote:
Does HT help or hurt in terms of throughput?


You wont get anywhere near double but you will get quite a bit more throughput by running 8 virtual cores instead of 4 physical ones.

Cheers,
Gary.

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6542
Credit: 287272542
RAC: 92964

Found an earlier discussion

Found an earlier discussion on the memory/CPU bounds thingy here. I think most of that discussion still applies ( my how time flies, it seems just like yesterday! ). Essentially ( where 'frequency' refers to the sought after gravitational wave signal frequency ):

Quote:

So the current run-time is the sum of a part that is determined only by the number of templates in each task (and can be derived from the currently assigned credit), and a part that varies with the (average) declination of the sky positions in the sky partition assigned to the task.

The trouble is that the ratio between these two is a little bit different of course for every App (version), but also for every machine, and finally also depends on the frequency (the higher the frequency, the larger the Fstat part). The Fstat part is FLOPs bound, it doesn't read or write much data, and depends on the speed of the FPU (or whatever SIMD unit the current App is using). The Hough part is largely limited by memory bandwidth, which is somewhat orthogonal to FP speed. The first App optimizations to the "Kernel loop" and "sin/cos approximation" addressed the Fstat part, while the recent "prefetching" affects the memory access of the Hough part.


Cheers, Mike.

( edit ) And later/earlier discussion also added the issue of compiler choice ( 'store forward stall' ).

I have made this letter longer than usual because I lack the time to make it shorter ...

... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

Snow Crash
Snow Crash
Joined: 24 Dec 09
Posts: 65
Credit: 100880785
RAC: 0

RE: It's perfectly OK to

Quote:
It's perfectly OK to start a new thread with a new question, so I did that for you. :-)


Thanks for that, I will try to be more discriminating in the future rather than just pulling a threadjack and thanks for the link and quote form the previous performance discussion.

Quote:
I presume you mean 1.375 Vcore?


um ... yes ... embarassing typo.

Quote:
My experience has been that the E@H apps tend to be quite hard on the CPU and I've seen examples of hosts that appear to be prime stable (or reported to be stable on other projects) that can develop errors when running E@H tasks. I regard prime stability as a good starting point from which to back off a bit so as to ensure no crunching errors. After all what is the point in saving a couple of minutes only to lose hours of crunching time if the occasional task starts failing well into the crunch cycle?


Yes, stability is the goal. I'll leave things as is, all errors so far have been self inflicted having nothing to do with OC.

So it sounds like the Einsein conventional wisdom is that I should leave HT on and the faster GHz your CPU can run the better.

Has anyone tried running the same exact same WUs with dual channel and then triple channel to see if there is any runtime improvement? How about tight timings or bumping up QPI frequency? If not I might set up a few runs to see what works best.

--------------------------
- Crunch, Crunch, Crunch -
--------------------------

Astromancer.
Astromancer.
Joined: 25 May 07
Posts: 5
Credit: 43595535
RAC: 0

While I'm no expert on E@H

Message 96170 in response to message 96169

While I'm no expert on E@H but... I can make some guesstimations about some things that may help.

As far as stability goes, I'm a bit crazy and run a program called Intel Burn Test set to max ram for enough runs to go for at least an hour. It'll peg your cpu with an insane load that will generate massive heat and most likely require the usage of a bit higher vcore than prime stability would. But if it passes IBT for an hour or so on max mem it's rock solid stable.

If something fails prime it's not calculating complex math properly, and that's all that BOINC projects do with your cpu so at least prime stability is needed.

On an i7 the memory bandwith is so monster high that tweaking it out for even more I'd think wouldn't be needed. But as I said I'm not a E@H expert, but if you could just crank the GHz on the older cpu's with lower mem bandwith and get faster computation, the same should be true or more true with an i7 and it's crazy mem bandwith.

I dunno how GPU OCing scales with this project, but with other projects I haven't found much of a gain from OCing the graphics cards. And you don't need to OC the core of an nVidia card for CUDA apps as all of the calculations are run on the shaders. (I'm 99% sure on that, someone please correct me if I'm wrong)

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6542
Credit: 287272542
RAC: 92964

RE: As far as stability

Message 96171 in response to message 96170

Quote:
As far as stability goes, I'm a bit crazy and run a program called Intel Burn Test set to max ram for enough runs to go for at least an hour. It'll peg your cpu with an insane load that will generate massive heat and most likely require the usage of a bit higher vcore than prime stability would. But if it passes IBT for an hour or so on max mem it's rock solid stable.


I have an i7 box so I'll give this IBT a run - with the case fans to the max. It has 6GB of Corsair at ~ 1.67 GHz. See if it falls over and/or what numbers I get. :-)

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter ...

... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

Snow Crash
Snow Crash
Joined: 24 Dec 09
Posts: 65
Credit: 100880785
RAC: 0

LinX is also extreme on the

LinX is also extreme on the CPU, I think it is just a nicer wrapper around the standard Intel IBT. This is what I use when I want to stress my cooling and start to quickly find the limits on new OC settings. I don't use it as my definative guide for crunching stability as I have been LinX stable but not Prime95 Blend at one time or another.

I have found that from a CPU utilization and core temps perspective that Einstein and WCG are about on par with each other. I have been overclocking and crunching for about 1 year now but I have never had a crash in WCG after making sure I can run Prime95 Blend for 2 Hrs. My Einstein experience has been the same with no OC crashes for me :-)

If you don't already have RealTemp I would sugggest taking a look at it to make sure your cores are not heating up too much. Your CPU should shut down if it hits ~100C and it's likely that your MOBO will automagically downclock if you start pulling too much juice (typical i7 around 1.35 VCore / 4.2 GHz). Keep an eye on the base CPU multi displayed in the top right of RealTemp to see if it is forcing a downclock. I have only seen that running LinX as Prime95 and crunching just don;t make the CPU work that hard. What I have observerd is that my core temps, as measured by RealTemp, are about 10-15 degrees cooler between crunching Einsein and streessing with LinX so don't be too worried if you get real hot. I typically don't like to run much above the low 70s but that really doesn't limit me too much as I am using a Megahalems cooler.

--------------------------
- Crunch, Crunch, Crunch -
--------------------------

Bill592
Bill592
Joined: 25 Feb 05
Posts: 786
Credit: 70825065
RAC: 0

RE: LinX is also extreme on

Message 96173 in response to message 96172

Quote:
LinX is also extreme on the CPU .....

I DLed LinX and gave it a try. Wow ! that really does stress the CPU.
More than anything I’ve tried before.

Here is a download link [url=http://www.youwatched.com/datajay/linx(0.64).zip/]linx(0.64).zip[/url]

http://www.youwatched.com/datajay/linx(0.64).zip

Thanks,

Bill

Snow Crash
Snow Crash
Joined: 24 Dec 09
Posts: 65
Credit: 100880785
RAC: 0

Give up the deets ... What

Give up the deets ...
What speed and VCore on your CPU?
Is it an C0 or D0 i7-920?
What were your max temps?
What are you using for a cooler?

--------------------------
- Crunch, Crunch, Crunch -
--------------------------

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.