Overclocking: No Effect?

Jonathan Jeckell
Jonathan Jeckell
Joined: 11 Nov 04
Posts: 113
Credit: 1,120,117,553
RAC: 450,175
Topic 198363

I recently overclocked my i7-5820k from the stock 3.3GHz to 4GHz and it made no difference at all to the average time to complete an Einstein FGRP4 work unit.

It's water cooled, and well below the max temp for the CPU. I don't see any CPU throttling going on, and the it's running at 100% load for all processors.

What could be going on? Also, paradoxically, my single fastest machine on a single core basis is a 2.6GHz i5, followed by a 2.66 GHz CoreDuo2 (of course, these aren't running GPUs either).

Another weird performance issue I can't explain fully:

I have an NVIDIA GTX960 (on Linux) that benchmarks as 12% faster than an NVIDIA GTX950 (on Windows 10), but the 960 is taking 57% *longer* to complete BRP6 units! Of course, this could be a Linux vs Windows issue, but generally things seem to run faster on Linux otherwise so that seems surprising.

Any thoughts? I would like to maximize the contribution from my investment in hardware and electricity to this project by figuring out what is causing these bottlenecks.

archae86
archae86
Joined: 6 Dec 05
Posts: 3,071
Credit: 6,023,224,462
RAC: 2,388,216

Overclocking: No Effect?

No difference at all from such a large clock rate change is a very odd result, and frankly, not credible.

Some possible sources of error:

1. The overclocking did not actually happen (I usually monitor with CPU-Z, backed up by watching temperature trends).

2. Not enough work was run at each of the two conditions in comparison for a proper conclusion to be drawn.

3. There is a changing mix of work types present on the system between the two conditions being compared. (possibly including non-BOINC interactive usage).

Particularly in mixed work scenarios, the oddities of schedulers can lead to somewhat durable imbalances on which of competing work opportunities gets serviced the most, and a surprisingly small intervention can alter this balance for a surprising time after the intervention has stopped.

Until fully diagnosed, I'd think it more likely that this is a case of faulty observation on an inadequately controlled experiment, rather than a big clue to a bottleneck in your production.

Jonathan Jeckell
Jonathan Jeckell
Joined: 11 Nov 04
Posts: 113
Credit: 1,120,117,553
RAC: 450,175

1. It could be that the

1. It could be that the overclocking didn't happen, but temps on all of the cores went up by 10C (with water cooling)

2. These observations were of about 50 work units (each, before and after) taken only about three days apart.

3. I acknowledge that it's possible that the nature of the work units changed. Two of my machines now take about twice as long to process FGRP4 units than they did a few months ago without any other changes, so... But the samples were taken pretty much adjacent to the change on each side.

archae86
archae86
Joined: 6 Dec 05
Posts: 3,071
Credit: 6,023,224,462
RAC: 2,388,216

In speaking of work types, I

In speaking of work types, I was not contemplating differences in the FGRP4 work, but in other work sharing the system during the tests.

I should translate that into a question:

During the two sides of the test, what applications were consuming noticeable (say greater than average 0.1%) CPU on the system? Was it just FGRP4? Probably not, as that host has a GPU you appear to use both for Parkes and for Arecibo work? Was the mix of Parkes and Arecibo the same on both sides of the test? Probably not. Was there Rosetta or SETI work running part of the time, but not balanced between the tests? Were you undertaking other non-BOINC activity which might not have been perfectly balanced?

I do agree that your observation of a 10C reported CPU temperature rise places the no overclocking attained possibility at very low probability.

We could speculate endlessly on possible mismatches, of which there are many. If the question is of real interest, I'd suggest rebooting the system before each side of a repetition of the test, and taking great care to constrain the active work load to be both as simple as possible, and as perfectly matched between the two sides of the test as feasible.

Jonathan Jeckell
Jonathan Jeckell
Joined: 11 Nov 04
Posts: 113
Credit: 1,120,117,553
RAC: 450,175

No other projects are

No other projects are running, except BRP6 with the same NVIDIA card on both sides of the test. The supporting CPU load was about the same all around.

The 10C temp increase (from ~40 to ~50) at 100% load at 3.3GHz and 4.0GHz respectively could indeed be real based on what I've seen with other people's water cooled systems. A lot of people overclock this CPU a *lot* more aggressively because of the headroom available with water cooling.

The room temperature was also identical.

Right now my suspicions center on RAM, since it didn't run all of the cores until I ramped up the amount BOINC can use to around 90%. I'm going to check the memory utilization when I get home (it's only got 8GB now). The machine is also capable of handling multiple RAM channels, but that would change the nature of the test.

chase1902
chase1902
Joined: 13 Aug 11
Posts: 37
Credit: 1,264,094,642
RAC: 0

I would also check what your

I would also check what your ram speed is set to.

I recently over clocked a G3258 up to 4.2 using software in windows rather than through the BIOS (I normally do it through the BIOS) and it reset the ram speed to a much lower speed (perhaps the standard).

It did take me a little while to work out what was going on as the run times did not fall as much as expected.

FGRP4 seems to respond well to increase ram speed, up to what your ram is rated at.

Jonathan Jeckell
Jonathan Jeckell
Joined: 11 Nov 04
Posts: 113
Credit: 1,120,117,553
RAC: 450,175

Well, I used one of the

Well, I used one of the pre-optimized settings in the BIOS that was supposed to adjust the clock speeds for the CPU, the RAM, the voltages, and all of that together into a stable configuration. Only all I am getting is more heat, and no sign of pumping up the FGRP4 production.

I will check that though. I also wonder if the available RAM is so tight that the amount of RAM is constraining it. I had to bump up the % of memory available to BOINC to something like 90% to get all 12 cores to process work units.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5,574
Credit: 81,948,939,741
RAC: 67,103,582

FGRP4 tasks do consume a lot

FGRP4 tasks do consume a lot of RAM - possibly as much as 300-400MB each if I remember correctly.

I find that FGRP4 crunch times do respond to overclocking. If you're not seeing it there has to be a reason.

Cheers,
Gary.

archae86
archae86
Joined: 6 Dec 05
Posts: 3,071
Credit: 6,023,224,462
RAC: 2,388,216

This is a long shot, but

This is a long shot, but might be worth checking.

The host on which I am typing had a repeating problem a few years ago that sometimes one of the (3) RAM channels would not "see" one of the sticks of RAM. Twice I got a warranty replacement on the entire set, but so long as I used the same model, it would happen again from time to time. Finally I got another model of another brand and no such trouble since.

Long preamble, short suggestion, just check to assure that in the overclocked state your system reports access to the expected amount of RAM. It will run if a stick is AWOL, but as you lose the parallel channel benefit, it would hurt RAM bandwidth rather a lot. Just barely possibly your motherboard interacting with your RAM might somehow have tripped into such a state when overclocked.

It should not be the case, of course.

Jeroen
Jeroen
Joined: 25 Nov 05
Posts: 379
Credit: 738,985,628
RAC: 0

This may not be related, but

This may not be related, but in my testing, I have found hyperthreading to offer no benefit with the FGRP4 application. I have previously seen hyperthreading increase the runtime by more than double compared to the runtime of running one task per core.

What you can try is download Process Lasso, and set the FGRP4 application CPU affinity to avoid non-physical cores. Set BOINC to use no more than 50% available cores.

With your CPU model and frequency, the runtime per task should be in the range of 16,000 - 18,000 seconds with this configuration.

Edit: I just saw your host is running Linux. In this case, you can use taskset to set each FGRP4 process to a physical core or disable HT in BIOS for testing.

AgentB
AgentB
Joined: 17 Mar 12
Posts: 915
Credit: 513,211,304
RAC: 0

RE: This may not be

Quote:
This may not be related, but in my testing, I have found hyperthreading to offer no benefit with the FGRP4 application. I have previously seen hyperthreading increase the runtime by more than double compared to the runtime of running one task per core.

Some time ago i tried disabling HT on my old i3-550 (dual GTX-460) and noticed quite a negative effect on total throughput when disabled. That said i was not really looking a CPU tasks at that (BRP4 app) time.

Quote:

Edit: I just saw your host is running Linux. In this case, you can use taskset to set each FGRP4 process to a physical core or disable HT in BIOS for testing.

Everyday is a schoolday in E@H - been using linux for years and did not know of taskset - thank you Jeroen, something else to tweak!

Comment viewing options

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