• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

MilkyWay@H - Benchmark thread Winter 2016 on (updated 1-2021) - GPU & CPU times wanted for new WUs

Page 5 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Finally some info on the card. 🙂 It's a fresh Windows 8.1 install with the FirePro driver only. Man, has a LOT of air moving through it, but still toasty and warm.

EDIT: FAHBench won't run, missing some .dll, says to reinstall, but that hasn't helped.

2ak0akn.png
 
Last edited:
I had a question about cpu_usage that probably doesn't deserve its own thread. I run Milkyway@Home GPU app only, and have an app_config that looks more or less like this on most of my M@H machines:
Code: 
<app_config>
<app>
<name>milkyway</name>
<max_concurrent>0</max_concurrent>
<gpu_versions>
<gpu_usage>.33</gpu_usage>
<cpu_usage>.33</cpu_usage>
</gpu_versions>
</app>
</app_config>

The thing is, there doesn't seem to be any change in behavior when altering the cpu_usage parameter from very small fractions up to 1. On my PCs, the process will take however much CPU it wants, when it wants, regardless of what app_config says. gpu_usage, on the other hand, seems to work up to a point, from 1 task to 4. Am I doing something wrong? What is cpu_usage supposed to do?
 
crashtech said:
I had a question about cpu_usage that probably doesn't deserve its own thread. I run Milkyway@Home GPU app only, and have an app_config that looks more or less like this on most of my M@H machines:
Code: 
<app_config>
<app>
<name>milkyway</name>
<max_concurrent>0</max_concurrent>
<gpu_versions>
<gpu_usage>.33</gpu_usage>
<cpu_usage>.33</cpu_usage>
</gpu_versions>
</app>
</app_config>

The thing is, there doesn't seem to be any change in behavior when altering the cpu_usage parameter from very small fractions up to 1. On my PCs, the process will take however much CPU it wants, when it wants, regardless of what app_config says. gpu_usage, on the other hand, seems to work up to a point, from 1 task to 4. Am I doing something wrong? What is cpu_usage supposed to do?
Click to expand...
I see the same thing on my AMD cards down to .05 for the CPU in MW. NVidia on the other hand I give a full CPU in app_config because I have seen those times get affected by CPU tasks running also.
 
My understanding is that gpu_usage and cpu_usage are not parameters to be passed to the application, but an advisory to the scheduler. The scheduler obviously needs to be told beforehand how many resources a queued task will take. Only then (and together with project priority, deadlines etc.) it can decide which tasks to start or to keep waiting or to suspend.

Now, gpu_usage and cpu_usage can be totally off of what the real usage will be. You already use that by setting gpu_usage to .33 to launch three tasks on the same GPU, even though a single task will take maybe .8 or whatever of the GPU if launched alone. (That is, you oversubscribe the GPU but gain better utilization, up to a point.)

Same with cpu_usage: It's make-believe towards the scheduler. With cpu_usage = .33 for example, the scheduler is made to believe that three feeder processes will be adequately served by one logical CPU.

If you set cpu_usage high, the scheduler might refrain from launching as many tasks as you intended, because the scheduler figures that the CPUs would be oversubscribed by another GPU job. Vice versa, if you set cpu_usage low, the scheduler will more likely see room for another GPU job and possibly oversubscribe the CPUs that way. (Just like a low gpu_usage causes the GPUs to be oversubscribed.)

As iwajabitw remarked, oversubscribing the CPUs can be OK on AMD cards, but may quickly be detrimental with NVIDIA cards.

Again, gpu_usage and cpu_usage do not influence the application directly. They influence the BOINC client's scheduler in its decisions, and thereby have (only) an indirect impact on the application due to GPUs/ CPUs being over/undersubscribed.

That's at least what I understood from my experimentation so far. The documentation that I found was a bit sparse.
 
@StefanR5R , that makes sense, thanks. So for my little dual-core machines that only run n identical GPU tasks on a single GPU, cpu_usage would not really seem to matter at all. It only is useful as a resource allocation tool to help with multiple projects, and in this role will require intimate knowledge of the behavior of the specific CPU(s)/GPU(s) combination to know what value to set, does that sound right?
 
I think it is important in both cases - only applications of a single kind on the box, or various different applications and projects active together. Though in the former case, it is far easier to predict how the scheduler will react on a particular cpu_usage setting. In the latter case, additional factors come into play, e.g. the importance that the scheduler sees in each project.
 
Since the change in MW tasks, (it's actually 5 tasks in a row, per 'zipped' downloaded task) each GPU thread seems to use to to an entire thread/core toward the end of each of the 5 tasks (20% mark on progress bar) for several seconds. So each compressed task will use 100% CPU at 5 different points along the progress.

I personally use the .05 CPU setting, because as Stefan says, it tells BOINC to go ahead and start another GPU task. This is more important when running CPU tasks, because I've seen BOINC NOT start a GPU task, because it didn't have a free CPU core/thread available. CPU task can wait BOINC! Gimme the GPU points BOINC!

In your case, single card, I think you have the best settings in App_Config, as long as nothing else needs CPU. Try to get the tasks to stagger out a bit, so they don't all hit the CPU at the same time, by letting them run for 15 seconds or so, then suspend one of the three tasks (a new one will start in it's place).

Worst case scenario, run two tasks. Not too big of a ppd hit, and still MUCH better output than single task.
 
<gpu_usage>.33</gpu_usage>

Change that to .5

1card /2tasks= .5
1card /3tasks= .33(repeating)

EDIT:

Ha ha! beat ya by half a second iwajabitw!

Personally I deleted the max concurrent line.
 
My dual 280x's are currently only doing two tasks, gpu temps were in the high 90C's.

Edit:
Single 280x is CPU & GPU set to .331 with Core2 Duo
Dual 280x's are .5 on both.
Dual GTX 980's are at CPU 1 and GPU .5 on Einstein.
 
Completely eliminates the need for further GPU-Time data then, at least on this thread. But at least we can still use the data on the first post as a yardstick, to get a feel for what you can expect from certain cards.

If Mark ever visits us again, he will no doubt create another benchmarking thread for the new task version. 🙂
 
Last edited:
Sorry guys, been away for a while 😱, blame my new flat & Elite Dangerous! 😉 😱, right, time to catch up on this thread.....
 
iwajabitw said:
Looks like todays server update is going to require new benchmarks. New version will be 1.46. Work units will progress 0%-100% instead reseting for each of the 5 tasks in the bundle. Also a credit increase for longer run times.

https://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=4125
Click to expand...
Ahh damn, didn't see this post! Looks like this thread will be a short lived one then!

And I'd (finally!) just added crashtech's Fury score! Thanks for your score 🙂, if you did benchmark the R9 290 I'll post that score too.
waffleironhead, added your RX 460s time too, thanks 🙂
I will add the scores already posted here, a few questions...

Stefan
What does COV mean?
Wow! You do have a ton of scores to add! 😀, I don't have time to add them all now, but I will at a later time, in the meantime I'll put a link to that post in the op.

Tony
Did you get a final benchmark for your Firepro before the MW update? (I'd often wondered about those cards with their awesome DP power! 🙂)
 
Last edited:
Assimilator1 said:
What does COV mean?
Click to expand...
Coefficient of variation = standard deviation normalized divided by mean,
i.e. a measure similar to standard deviation, but normalized.
(Hmm, maybe "CV" is more often used to abbreviate coefficient of variation.)

You can safely ignore these values in my posts; they are only there to show that variation was reasonably small, AFAIR.
 
iwajabitw said:
Looks like todays server update is going to require new benchmarks. New version will be 1.46. Work units will progress 0%-100% instead reseting for each of the 5 tasks in the bundle. Also a credit increase for longer run times.

https://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=4125
Click to expand...

I'm outta touch here, so beyond fixing the progression bar issue did v1.46 change times or credits vs v1.4? (2 or 3?)
I'm confused atm as to whether this thread is obsolete or not! 😉 (I've just added a new, fastest, time to the table too! (tictoc's).
 
Assimilator1 said:
I'm outta touch here, so beyond fixing the progression bar issue did v1.46 change times or credits vs v1.4? (2 or 3?)
I'm confused atm as to whether this thread is obsolete or not! 😉 (I've just added a new, fastest, time to the table too! (tictoc's).
Click to expand...
Honestly haven't ran MW fulltime in months, just the Formula Sprint last month. Work credit was almost doubled, but I can't comment on times for single wu since I had 2-3 tasks going at once for the race. Sorry.
 
Ok, I've finally got around to looking into the above issue (credits & WU times from v1.42 to v1.46), & if I'd looked at iwajabitw's link in the 1st place I would've saved myself a lot of time! Lol

So from MWs Jake Weiss post on the 1/5/17 :-

Application completion percentage now goes from 0% to 100% only once.
- Context: When workunit bundling was first implemented, the workunit completion percentage would go from 0% to 100% once for each workunit in a bundle. Now we have fixed it to count from 0% to 100% only once regardless how many workunits are bundled together.

Credit Update to reflect longer workunit times.
- Context: Adding the disk model increased the run time of the application slightly. You should see an increase in credits per workunit to reflect this.

I've no idea what he means by 'the disk model', but he clearly states that the run time's increase slightly, so this benchmark thread is, & should've been over since then, damn 🙁.
I will remove any results from the table that were posted after 1/5 so as to not have mixed results there, & I will post them in a little table here so as not to just toss away the data.

As for creating a new benchmark thread, well I guess I will if there's (grammar??lol) enough interest, hint, post your v1.46 times here 😉. If I get enough I'll start a new thread 🙂.
Bearing in mind my visits are sporadic here, it won't be a quick turn around 😉
 
Ok, seem to be no results posted here after 1/5/17, that was easy! 🙂
Now to check results from the MW forums....... seems it was just Tictocs time!

Looking through over 2700 results from 2 of Tony's PCs, over 99% of them were 227.23 credit WUs, with just a handful being 227.26 & a few 454.35 credit WUs.

Tony - Btw, I assume you're running multiple WUs at once on your GPUs?

So, for v1.46 WU times please use the 227.23 credit WUs 🙂 (although I can't imagine the 227.26 WUs would take much longer!).
 
Last edited:
Some fresh, one task at a time results are on the way if you want to look over the results. But yes, typically I run 3 at a time. (R9-280X, Windows 10 64, HT)

EDIT:

Haswell-E Xeon at 2.5GHz, 1000MHz/1500MHz about 55 seconds (both cards)
Haswell Pentium at 3.0GHz, 1000MHz/1500Mhz about 52 seconds (first card)
Haswell Pentium at 3.0GHz, 1100MHz/1500MHz about 48.2 seconds (second card)

Also of interest, only ~15 seconds of CPU time at 3GHz, but ~22.5 seconds at 2.5GHz. CPU is most certainly a large variable in these shorter tasks.
 
Last edited:
Cool, thanks 🙂.

Running it on my main rig for a bit too, so far my HD 7970 is running them in about 54s, which makes me wonder about tictocs time, even if I cut the time by 25% (his o/c compared to my GPU), then that would give a time of about 40.5s, maybe his result is older than I thought........ [edit] yes it is! Doh! IDK how I missed that, he posted in April.

I'm going to move the new v1.46 table to the op to keep it easy to find, I'll create a new thread if it get's big.

Re 227.23 vs 227.26 credit WUs

It seems my HD 7970 is averaging about 53.s (visual average of nearly 170!) for 227.23 credit WUs, & so far I've only got 3 227.26 WUs which average out to 56.08s.
So they seem a little bit longer, but that's only from 3 WUs.
 
Last edited:
You must log in or register to reply here.

TRENDING THREADS

Back
Top