I have just stayed away from ATI/AMD because of the challenge of installing the drivers and maintaining them. The Nvidia drivers just install and run with no issues ever. The ATI/AMD drivers are a complete fiasco as all the constant posts of issues posted attest in the forums.

True enough for the latest versions. But the RX 500 series is easy enough as I understand it, though mine is on Windows. And the power efficiency of AMD is much better here; I use about 90 watts (GPU-Z) on my RX 570 for my 100 seconds; I expect it would be more like 140 watts on the Nvidia cards.

I have a bunch of Nvidias, but they are used elsewhere (on Ubuntu).

I seem to do the work units in around 100 - 140 seconds for both my 1080 and 2080. And around 90 seconds for my 1080 Ti.

MW used to have a mt N-body application in earlier times. GPUGrid.net currently uses an mt application called QC Chemistry that heavily uses multiple cores with default of <cmdline>--nthreads 4</cmdline>. When the application first was developed it defaulted to using all cpu cores until users complained and it was knocked down to something more sensible.

Primegrid has a ton of cpu apps and MOST can be multi-threaded like that, so can the ones at RakeSearch, SRBase, I think Universe and others I don't remember right now. The easiest thing is to try it and see if it works, you have the basics now just change the app name which is listed under apps on most projects and put the app_config.xml file it in that projects folder.

Okay, this is a strange issue.

I decided to enable CPU tasks in prime grid project settings. And what do you know, that machine is getting tasks like crazy on the CPU side of things.

Should I try resetting MWH? I have little experience in doing this so not sure if I should outright remove or reset project. I'm assuming make sure there are no tasks left before doing either one.

Interesting and a little frustrating, but hopefully I can figure this out.

Resettting will wipe out every workunit from MW you have on your pc in the process.

Are you sure you have the allow cpu tasks checkbox checked for MW? Were you running cpu wu's from other projects prior to allowing them from PG? What is your resource share set too?

I'm used to coming off of WCG, where just about every project is pretty consistent with the runtimes you receive.

And I'm used to the varying runtimes of the tasks we get at Seti depending on the origin of the tasks (which antenna) and also the way the data was gathered. Typically one type of task from Arecibo telescope takes twice as long to compute as a task from Green Bank telescope even thought the task sizes are identical. I just realize that some tasks from any particular project are easier or harder to crunch and don't worry about it.

MW used to have a mt N-body application in earlier times. GPUGrid.net currently uses an mt application called QC Chemistry that heavily uses multiple cores with default of <cmdline>--nthreads 4</cmdline>. When the application first was developed it defaulted to using all cpu cores until users complained and it was knocked down to something more sensible.

I'll help with the battery first, just remove the battery and run it off the wall like a desktop, no more battery problems.

As for not using all of the gpu it depends on the OS you will put on it, if it's Windows then you can use something like MSI Afterburner to change the settings to slow it down a bit. I have no clue what program in Linux will do the same.

Does this work on all CPU projects or only on a few?

<cmdline>--nthreads 4</cmdline>

<cmdline>--nthreads 4</cmdline> is an actual command line option (could be for numerous other options besides multithreading) passed onto the WU application at startup and syntax depends on the coding culture of the author.
LLR.exe accepts "-t4", not sure it accepts "--nthreads 4"

If you don't pass on the option exactly the way the application expects it, then no multithreading.
If a project's WU doesn't actually have code to multi-thread, then the command line option is meaningless, so it will only work on CPU work units that are ready for multithreading.

(Sorry Keith, that was off topic, but interesting question to be answered)

Does the estimated computation size not have anything to do with how long the task takes? Seems like the bigger WU is going to be much shorter (less than half the time) as the theoretical shorter and smaller one.

Yes, generally it does. But is also depends on how the project scientists setup the application's expected results for a calculation. Some tasks are more difficult than others and may require more FLOPS to compute. The calculation difficulty also factors into how much credit is awarded in the classic BOINC code. But the creation of the CreditNew credit algorithm pretty much threw a monkey wrench into that business. That topic is a political minefield. The project scientists determine how much and how they award credit.

I would not bother with reinstalling Windows. That won't change the difficulty in different task calculations. You are trying to compare apples to oranges. Just let BOINC run and do its thing. You can't change how it works.

There are a few tasks in progress that are going to take well over a day and appear to be only 15000 gflops and a bit. Meanwhile a core i5-3317U can complete a task of 60000 plus in less than half this time. So something is definitely going on,

I discovered after making a purchase for a used GPU, that Milkyway requires double precision floating point calculations and the 1060 3gb was 1 FP64 to every 32 FP32 calculation units. (Ended up buying a used 280x for Milkyway)
The benchmarks shown in details here, I think, reflect FP32 measurements, not FP64.
It's possible the performance difference on Milkyway WU between the i5-3317U and your Ryzen could be related to double precision abilities.

Do you have a BM tool that measures FP32 and FP64 you can test on the two CPU's to compare?
Or at least to see if your Ryzen is performing at expectations to reference BMs.
Speaking of reference BM's; here's a site taking a Ryzen 1700x through it's arithmetic paces using the Sandra Lite application.
The Ryzen 1700x seems to have good FP64 , and if the 1800x (not finding their 1800x review) isn't much different in architecture, it should be outperforming the i5-3317U.

Maybe I just need to format? Not sure what else to look for.

Before you do that, to eliminate the OS and app install, you can run a testing OS from a USB thumb drive which is a barebones, OS built only to do BOINC and see how well the hardware does on that reference OS. I made one with Tiny7 but there is PenDriveLinux and others. You can use YUMI to build a pendrive Linux from many different distros.

Anyway, you had 6 errors out of over 600 WU's, it could just have been a power spike. But the performance difference between those two machines would bother me, especially since the 1800x is a workhorse.

Well I was just about to ask about multithreaded CPU applications. Looks like I no longer have to since they've apparently been phased out.

An app_config.xml file will let you do it manually if you want too, most cpu apps can be done that way but not all.

This should work in your app_config.xml for 4 threads (check the client_state.xml for this information).

<app_version>
<app_name>milkyway_nbody</app_name>
<plan_class>mt</plan_class>
<avg_ncpus>4.0</avg_ncpus>
<cmdline>--nthreads 4</cmdline>
</app_version>

Ignore the estimated time remaining. That is only a guess by BOINC since it has only seen 5 tasks so far on your host. BOINC can't accurately predict runtimes on tasks until the host has validated 11 tasks for each application that are not overflows, 100% radar blanked or errors.

Those are probably not errors. Those are the work units that most other projects call 'validation pending' or 'pending' (not sure why it's different here).

Those WU's are waiting for the wing-computer to report a second result and they may wait for up to a full deadline period if the computer got shut off, project detached without aborting the WU's, etc...


You have 6 actual errors, and like Beemer pointed out, could be your computer temps.

Two of the GPU were error: 3x "C:\Users\tcwoo\AppData\Local\Temp\\OCL8928T1.cl:186:67: warning: unknown attribute 'max_constant_size' ignored".
Not sure what that one is.

The 3 invalid on the CPU were only your computer's problem so check for cooling issues, running out of RAM (bad app, leaking memory pointers), hopefully you're not looking at an actual hardware problem.

Yes your work cache covers both cpu and gpu work. BOINC determines whether there is room to schedule cpu or gpu work based on the total amount of estimated calculation time spread among all your projects. It is called REC or Recent Estimated Credit and that figure gets used along with GFLOPS for each device in round-robin simulation when you request work. One of the ways to see what your total commitment for the cpu is to set work_fetch_debug in the Event Log logging options and then read through the Event Log after the work request. You don't want to leave it enabled for more than one work fetch cycle though because it generates a lot of output. A good option to set is sched_op_debug as a permanent logging option. It doesn't add all that much to the event log but it does show you exactly how many seconds of work you are requesting for both cpu and gpu that totals up to your days of work cache size. This is a snippet out of mine to show as an example. My work cache settings is 0.5 days of cache and 0.01 days of additional work cache. Your additional days of work should be set very low to make MW@home request work every 91 seconds.


To see what kind of commitment you have among all your attached projects, you can set rr_simulation. I think that will show you are too overcommitted to the WCG cpu task. I believe that will cause issues since even if you have a very small work cache set, just one WCG task in your work cache will swamp any other cpu work. The way to get the MW N-body mt (multi-thread) application to pull some work would be to suspend the WCG task. It may take a while for BOINC to "balance the books" and let you download a mt task. You might have to leave the WCG task suspended for a few days and hope that it doesn't go into High Priority mode once re-enabled. Try to set your work cache to a very small amount. That increases your chance of getting some MW mt tasks.