Welcome to MilkyWay@home

Posts by marmot

1) Message boards : News : Where MilkyWay@home Was The Last Few Days (Message 70797)
Posted 18 May 2021 by marmot
Was it a profit making attempt through encryption->ransom or cyber intelligence gathering?
2) Message boards : Number crunching : So??? Where's Milkyway@Home been the last few days? (Message 70796)
Posted 18 May 2021 by marmot
Please see this thread: https://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=4720#70788


I only keep up to date at these forums on project status.
3) Message boards : Number crunching : So??? Where's Milkyway@Home been the last few days? (Message 70782)
Posted 17 May 2021 by marmot
You just going to let us wonder?
4) Message boards : News : Multi-threaded N-body is back (Message 70735)
Posted 14 Apr 2021 by marmot
Question about credit:

For tests on my one machine (unhidden in preferences now https://milkyway.cs.rpi.edu/milkyway/results.php?hostid=803986&offset=0&show_names=0&state=4&appid=), which is a v1 2665 Xeon (down clocked for lower heat) Separation takes 18k seconds for 227 credit (not overbooked) while N -Body is about total CPU of 10k-12k and running between 35-44 credit.
Since credit is based on total run length, and not CPU run time, at some projects; as a test, I over booked the 16 thread N-Body so the run time averaged about 9k seconds (5k to 18k run lengths) and the credit didn't \vary from the aprox. 40 credit on the first, normal, N Body test runs (about 1300 second run times).

Shouldn't an N Body that comes close to 1 core usage have similar credit to Separation WU's?
On average this machines N-Body (overbooked) give about 65 credit per 18k seconds CPU usage while Separation gives 227 credit per 18k CPU usage.

I search the forums for this discussion but not even the Google based search seemed to find a prior discussion.
5) Message boards : Number crunching : Updated GPU Requirements (Message 68773)
Posted 22 May 2019 by marmot

I'll try the latest Catalyst on the 7490m and see if some Milkyway WU's start up.
(Looks like AMD freezes it at either 15.7.1 WHQL 7/29/2015 or Crimson beta Edition 16.2.1 3/1/2016, it's currently on Catalyst 14.9)

Correction: It's a Radeon HD 7450m w/ OpenCL 1.2 capability and 1GB RAM.

Milkyway won't send GPU WU's to it.

So just being capable of OpenCL 1.2 isn't enough.
What's the other criteria?
6) Message boards : Number crunching : AMD FirePro S9150 (Message 68753)
Posted 19 May 2019 by marmot



That's almost the perfect the MSI control panel (voltage control is missing, that might require custom BIOS mod) you want to see.

I have my S9x00 boards working fine with the 2015 driver and have been able to set the clock speed whereas I could not do that with AMD latest "Pro Series".
The driver coders seem to be exclusively concerned with currently selling GPU's and won't protect older card functionality on new drivers. especially ones with a low user base. Encourage people to buy new and keep up the myth on majority of discussion forums that it's always best to use the newest driver. [/rant]

I then downloaded and extracted AMD_OpenCL64.dll from both the 2018Q4 and the 2019Q2 and put those at \windows\system32 and also at \windows\SysWOW64
Looks like I am stuck with the correct driver but a 4 year old opencl library.
How is your invalid rate on the 2015 opencl and driver? Has your credit/second improved by 710mhz/511mhz=39% ?

If you have 200 runs on the 2019 driver/newest OpenCL, and know the average GPU clock speed (~511), then do another 200 runs at the improved average clock speed(~710) on the 2015 drivers, you could compare the performance adjusted by CLOCK1/CLOCK2 and see if the older drivers are slower than expectations.

It would be impossible to determine if the speed increase is from the base driver or improvements to OpenCL code if you can't keep the same driver while swapping OpenCL. Seems like there could be a way to trick the newer OpenCL to work.
7) Message boards : Number crunching : Long crunch time on new N-Body simulations? (Message 68752)
Posted 19 May 2019 by marmot
Well, this isn't very surprising since the new application is using only one single core.
Ok, true, but I think the estimated completion time is being under-estimated. I had some tasks that took 24-26 hours to complete, but I think they were originally estimated at 11 hours or so. I didn't pay close enough attention to know for sure if this is the case. I'll have to check upcoming tasks to see if this is really the case or not.

BOINC client keeps a running average of completion times to estimate completion and the old runtimes outweigh the new runtimes in the average.

I think if you set, in cc_config.xml, <rec_half_life_days>0</rec_half_life_days> then restart BOINC and run it for an hour then set it back to default 10 days <rec_half_life_days>10</rec_half_life_days>, you'll reset the running averages (of all WU's) and it should be close to the right number in 24 hours.

I don't usually worry about the estimate (it's usually always wrong) and so haven't tested this.
8) Message boards : Number crunching : AMD FirePro S9150 (Message 68732)
Posted 15 May 2019 by marmot
I tried the latest MSI even the beta version and when I clicked on the APPLY checkmark the changes I made want back to the default.

I had to go to an older non-WHQL driver to get the Power control to functionality back on two of my cards. (Installing more than 2 years newer driver past the manufacturer date on a card increases the risk of planned obsolescence problems).
Tried about 9 drivers, 17.11.4 was the winner.

Do you see the custom fan profile tab under MSI configurations? I get the feeling you're not concerned with fan sounds. Forcing my cards fans to 100% by 61C, with a custom MSI fan profiles, has made all of their BIOS algorithms decide to delay actions to reduce heat, leading to higher clock speeds.
9) Message boards : Number crunching : AMD FirePro S9150 (Message 68729)
Posted 13 May 2019 by marmot

I show 550-650 and rarely hit the design of 825 as you can see in the graph.

That brings me back to my earlier question; does MSI (or Linux equiv app) properly downclock, downvolt or down power your S9100?

Do you have ability to control the clocks or power meter?

If the internal BIOS of a GPU decides it's temp is too high, it downclocks and downvolts.
If you raise the power meter percentage then it waits till higher temps to start downvolt/clocking.

The S9100, which is a server card, might be deciding to start at the 60C showing in the graph.
Increasing the power meter to +25% -> +50% might get it to peg top clock regularly.

If BIOS/driver, won't give you access to the power meter then custom fan profile with MSI, set to hit 80% fan speeds by 58C, 100% by 62C would convince the BIOS algorithm to let the clocks run higher as the card is forced to cool off sooner.
10) Message boards : Number crunching : warnings & errors (Message 68728)
Posted 13 May 2019 by marmot

Made the change but don't know how to confirm the thread count. Where would I look?

I use a task manager, like Process Hacker, and look at the CPU usage of the WU.

Since you have 24 cores, a single threaded process will use 1/24 ~= 4.1 % under CPU usage.

4 threads should be using ~16.6%. You can use the properties feature of many task managers to look at the internal threads.
You should see 4 identically named child processes taking up 4.1% CPU and have much CPU cycles of usage.

I thought the app_config would assign multiple cores to a single task? Perhaps speeding up the computations?

BOINC doesn't have an AI to perform that manipulation. On some projects you'll just have to choose properly in project settings, some projects default to multi-thread (YAFU, XANSONs, etc.), while some projects are capable of multi-threading but it's a hidden feature you need to use app_config to enable.
Keep an eye out for optimized applications that you can optionally add also. SETI has one which has some partial multi threading.

<ngpus>x</ngpus> - the number of GPU instances used by the app

If nbody is a CPU task then what is the purpose to adding this line in the app_config file?

Milkyway has GPU WU's and the app_config.xml covers all WU's under Milkyway so if/when you run some GPU WU, it'll be useful.

avg_ncpus tells BOINC how many threads to reserve for the job scheduling

This is number of CPU's you want each WU to attempt to use (where it might use less in certain phases). It's a per WU variable.

cmdline tells BOINC how many threads the application may use at maximum
Milkway Nbody tasks can run on any number of threads that you care to set for them, but do keep the numbers you use for avg_ncpus and nthreads equal.

What you had built in your first post was fine, just make sure the cmdline is '--nthreads 4'.

Lastly, changes to app_config.xml or cc_config.xml don't take effect until you go to the advanced menu on BOINC Manager and select options -> read config files and you'll see the WU's readjust to the new settings in a few seconds.
BOINC Manager has a bug that it won't show the changes in the work unit descriptions even though the changes take effect.
So, it's usually best to shut down BOINC and restart it unless (and there are some) a project's WU doesn't make proper save points and will lose hours of work or some rare WU's will die upon suspension/restart (not naming names, but one I know of using Oracle VM WU's).

To make an app_info.xml (for anonymous platforms) change take effect, you must restart BOINC.

This info will help you out on all projects.
Good you are asking.
11) Message boards : Number crunching : warnings & errors (Message 68719)
Posted 12 May 2019 by marmot
Looking at the task output I'm seeing some errors & warnings and don't know how to address them.

<search_application> milkyway_separation 1.46 Windows x86 double OpenCL </search_application>
Reading preferences ended prematurely
BOINC GPU type suggests using OpenCL vendor 'Advanced Micro Devices, Inc.'
Error loading Lua script 'astronomy_parameters.txt': [string "number_parameters: 4..."]:1: '<name>' expected near '4'
Switching to Parameter File 'astronomy_parameters.txt'
<number_WUs> 4 </number_WUs>
<number_params_per_WU> 26 </number_params_per_WU>

This error is in all my valid work units visible.

You can ignore it.

C:\Users\jnedd\AppData\Local\Temp\\OCL8644T1.cl:183:72: warning: unknown attribute 'max_constant_size' ignored
__constant real* _ap_consts __attribute__((max_constant_size(18 * sizeof(real)))),
C:\Users\jnedd\AppData\Local\Temp\\OCL8644T1.cl:185:62: warning: unknown attribute 'max_constant_size' ignored
__constant SC* sc __attribute__((max_constant_size(NSTREAM * sizeof(SC)))),
C:\Users\jnedd\AppData\Local\Temp\\OCL8644T1.cl:186:67: warning: unknown attribute 'max_constant_size' ignored
__constant real* sg_dx __attribute__((max_constant_size(256 * sizeof(real)))),
3 warnings generated.

I've seen the warnings before too, asked about them and told they can be ignored.


Is this syntax giving you 4 threads?
Always seen this as integer input:
<cmdline>--nthreads 4</cmdline>

Also, looking in the project directory I no longer see the GPU configuration xml file for milkyway_1.46_windows_x86_64__opencl_ati_101. Is this not supported?

This, I do not know the answer to and would like to see the response.
12) Message boards : Cafe MilkyWay : Don't mess with us... (Message 68716)
Posted 10 May 2019 by marmot
we'll give you the plague...

13) Message boards : News : New runs of MilkyWay Nbody out (Message 68715)
Posted 10 May 2019 by marmot
Great news, everyone! The app selection preferences are available again in the Project Preferences! You can now choose to opt out of Nbody or Separation. Thank you all for your help in getting this feature back!

Good job!
14) Message boards : Number crunching : So no way to select project campaigns anymore on the new server code (Message 68711)
Posted 9 May 2019 by marmot
I think Universe and others I don't remember right now.

All the LHC@home WU's can multithread,
YAFU is all multithreaded work.
Cosmology is VM (boinc2docker) multithreaded
Amicable Numbers CPU work is minimum 2 cores.

RakeSearch has a user created optimized app that's supposedly faster than mt.
15) Message boards : Number crunching : AMD FirePro S9150 (Message 68710)
Posted 8 May 2019 by marmot
downgraded driver to 18.Q3, but still getting invalids when running multiple WU per GPU

The newest drivers (19.4.3, 19.3.1) ended up getting no invalids on 4+ WU per on the 280x. 18.7.1 had a small speed increase but also had 5% invalids over 4WU. BTW, it's the last driver that works properly on Enigma GPU WU's.

Had to drop to 17.11.4 to get Amicable Numbers to work most efficiently.
17.11.4 also was the only driver of about 9 I tried that gave MSI Afterburner actual control over the power slider on my RX 550.
18.5.2 also worked efficiently on Amicable Numbers, for both 280x and RX 550, but no power sliders.

Sorry, haven't gotten around to testing 17.11.4 on Milkyway because Amicable is nearing the end of their ^20 dataset and hunting a WUProps badge and some Mag.
16) Message boards : Number crunching : AMD FirePro S9150 (Message 68709)
Posted 8 May 2019 by marmot

My 9100 has a high power blower and it barely cools the board. I had to tape it on
as shown cuz it fell off once and the system shut down in seconds.

I was thinking of getting one of these, for the co-processor PCIe slot in my IBM M-series server, this coming winter. The CPU fans are to blow air through the board... but in spring and early fall, the CPU's are downclocked to minimum and the fans stay around 1000 RPM.

Not sure it would be properly cooled unless it also was downclocked or set to a cooler running project like Amicable Numbers (which will be done with ^20 by fall, unsure of it's future).

You've been able to get MSI (or Linux equiv app) to properly downclock, downvolt or down power your S9150?
17) Message boards : Number crunching : So no way to select project campaigns anymore on the new server code (Message 68698)
Posted 6 May 2019 by marmot
They are still debugging a QC Chemistry app for Windows hosts.

Got 30 machines trying to get a hold of some of those.
Deleted 3 on a machine that got some because I was doing maintenance/rebuild and it would be down for 2 days. I didn't know the rarity.
Another WUProps WU with less than an hour runtime probably stuck on my record....

BTW, the most common WU's with plentiful work are:
SRBase and Primegrid (where ever the LLR.exe app is used) can run multi-threaded but you'll need to setup the app_config.xml
All the LHC@home WU's can multithread, Theory has to be setup for MT and has too much single thread time, but CMS and ATLAS thrive on MT.
YAFU is all multithreaded work (handled by the wrapper), up to 64 cores (maybe more).
Cosmology is VM (boinc2docker) multithreaded as well as any other project using the boinc2docker VM for work, so BOINC TACC (Texas), nanoHUB (both low work).
Amicable Numbers CPU work is minimum 2 cores.
I think CAS@home and BURP are MT, but can't get any work from them to find out. BURP's mission was way more important 10 years ago.
18) Message boards : Number crunching : Errors, invalid, and validation inconclusive. Anything to worry about? (Message 68697)
Posted 6 May 2019 by marmot

I don't think this supports running 2 WUs at once on the graphics card - I'm seeing 100% utilization at around 78 Celsius. It's very tempting to go for the rx580 or even 590, or maybe wait for AMD to drop the ball on the new 7 NM, but I'd mainly be getting that for crunching rather tha

You should be able to run 8 on that card. My RX 550 4GB did and stayed around 61C but it's also only a 32W card.
19) Message boards : Number crunching : So no way to select project campaigns anymore on the new server code (Message 68679)
Posted 4 May 2019 by marmot

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)
20) Message boards : Number crunching : Errors, invalid, and validation inconclusive. Anything to worry about? (Message 68678)
Posted 4 May 2019 by marmot
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.

Next 20

©2021 Astroinformatics Group