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

[TennesseeTony]

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.

 

[Orange Kid]

Added a link to this thread in the Project List thread under MilkyWay@Home

 

[crashtech]

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:

<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?

 

[iwajabitw]

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:

<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?

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.

 

[StefanR5R]

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.

 

[crashtech]

@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?

 

[StefanR5R]

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.

 

[TennesseeTony]

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.

 

[crashtech]

Such good info, guys, I'm a little slow at getting my head around this stuff, and do appreciate the hand-holding.

...Worst case scenario, run two tasks...

Do you mean by using max_concurrent value of 2, or something else?

 

[TennesseeTony]

<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.

 

[iwajabitw]

Such good info, guys, I'm a little slow at getting my head around this stuff, and do appreciate the hand-holding.


Do you mean by using max_concurrent value of 2, or something else?

GPU setting of >.5< is 2 tasks per card.

Edit: Same time Tony!

 

[crashtech]

GPU setting of >.5< is 2 tasks per card

Yeah, that much I have figured out, in fact my example shows the config for three tasks. I wasn't sure if something else was meant.

 

[iwajabitw]

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.

 

[iwajabitw]

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

 

[TennesseeTony]

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.

 

[Assimilator1]

Sorry guys, been away for a while , blame my new flat & Elite Dangerous! , right, time to catch up on this thread.....

 

[Assimilator1]

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

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! )

 

[Kiska]

@Assimilator1 I started with my R9 280x, so here sort through the results!
https://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=733133
Looks like every 54 seconds I get 227.23 credits
R9 280x running at 1050 Mhz on the core and 1500Mhz on the memory with a +20% power limit increase

EDIT: I am experimenting with 1100Mhz on the core and 1525Mhz on the memory with the same power limit increase

 

[StefanR5R]

What does COV mean?

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.

 

[Assimilator1]

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

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).

 

[iwajabitw]

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).

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.

 

[Assimilator1]

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

 

[Assimilator1]

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!).

 

[TennesseeTony]

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.

 

[Assimilator1]

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.