Welcome to MilkyWay@home

Posts by Peter Hucker

1) Message boards : Number crunching : Run Multiple WU's on Your GPU (Message 70421)
Posted 21 Jan 2021 by Peter Hucker
Post:
Your 3090 will crush tasks at primegrid....... although I've seen with GFN-16 tasks, its not much quicker than a 3060Ti! Same can't be said for other PG sub projects though where the 3090 will be king.
It seems impossible to get a straight answer anywhere as to which projects use DP (and are therefore best on old AMDs) and which are SP (which are therefore best on new Nvidias). Presumably the developers must know!

Mainly from my own testing with a few cards to see how fast they go, it appears that:

Einstein=SP
Milkyway=DP
Collatz=SP
Primegrid=half of each
2) Message boards : Number crunching : Run Multiple WU's on Your GPU (Message 70369)
Posted 15 Jan 2021 by Peter Hucker
Post:
Some projects do do better with Nvidia cards but as you said those requiring DP do better with AMD cards.
I'll be getting a very fast Nvidia one day for a game, I guess I'll allocate that to SP projects only. Unless I find an AMD that's as good. I need 4K at 120 frames per second.
3) Message boards : Number crunching : Run Multiple WU's on Your GPU (Message 70347)
Posted 13 Jan 2021 by Peter Hucker
Post:
You need to build a tired old PC and add a few HD 7970 or R9 280X cards to it....

Just because Nvidia sell you a high priced item doesn't make it suitable for efficient use on this project.

I bought a used Gen 1 GTX Titan Black for the high DP and extra RAM, but it is still 3x slower than a cheap R9 280X.

I currently run a Radeon VII and spews out a result every 11 seconds, running multiple tasks on a quad core CPU.

I would say Nvidia cards would be better used for GPUGrid, but they have no work available....

dunx
Yip, I always get old AMD cards for Boinc. I'm appalled at Nvidia's attitude making the DP so slow.
4) Message boards : Number crunching : Run Multiple WU's on Your GPU (Message 70339)
Posted 12 Jan 2021 by Peter Hucker
Post:
Hi Guys,

So I have tried running more than one unit and I can't get much of a boost from it, so for example, if I run 1 unit the completion times are around 1:40, if I run 2 they are around 3:30 so if anything they are running slower.
GPU is an RTX 3090, I checked the power usage and on a single unit it's pulling around 190w, and for two it's around 215w, I tried up to 5 and it seems to cap at 215w no matter the number of units.
The card can pull up to 350w under full load (Einstein does) so it feels like for whatever reason MW@H cant fully utilize my card even with multiple WU's.
Any ideas on how to fully use the card with multiple WU's?
My config is for two units:

<app_config>
<app>
<name>milkyway</name>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>0.05</cpu_usage>
</gpu_versions>
</app>
</app_config>
You may or may not get a boost, it depends on your CPU and GPU relative speeds. Ignore what I said in my last post, I'm now doubling up in some circumstances. If the CPU is slow (per core, as the tasks will only use 1 core) and the GPU is fast, then doubling or more will help. If you have a good CPU and it's not doing much else, and your GPU isn't that fast, then you might not need to. It also depends on what you're running on the GPU, some projects have apps that require more CPU than others. Einstein needs a lot, Collatz doesn't need much at all. MW needs it in chunks as it starts each of the tasks inside the bundle (currently a bundle of 4, so you'll see it pausing at 25, 50, 75%). What I do is watch the GPU usage in something like GPU-Z or MSI Afterburner, something with a graph of usage. If it's pretty much 100% all the time, leave it alone. If it's dipping a lot, try doubling and see if it goes higher. You can also try freeing up CPU cores.
5) Message boards : Number crunching : Run Multiple WU's on Your GPU (Message 70280)
Posted 27 Dec 2020 by Peter Hucker
Post:
Perhaps related,
For Nvidia RTX 2000 series GPUs, anything above 2 is useless.
The RTX 2080 Ti does 3 WUs at the same time as it does 2WUs, a tiny bit faster, but it'll also consume about 10W more power ( 5%) for finishing 2x3 WUs in less than 5% difference in time of 3x2WUs.
AMD GPUs are a bit better for Einstein and Milkyway, because they have more DPP.
Einstein is SP.

I think because Milkyway is using DPP, more than what the GPUs actually have to offer, and thus is bottlenecking the GPU by a lot! (80-140W usage out of 150-195W limits).
If that's the case, you could set GPU to 0.33 and 0.25, on RTX3080 and 3090.
Fine if you add another task that isn't MW. But two MW will not magically create more DP units in your card. Doubling up the same type of project on one card only solves one problem - the CPU is holding up the GPU.

I've ceased bothering anyway, it doesn't gain you that much in any scenario.
6) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70112)
Posted 5 Sep 2020 by Peter Hucker
Post:
You are confusing task deadline and resource shares for the needs of the REC scheduler. You need to read up on that. The REC scheduler is the next highest arbiter of which tasks should run after task deadlines. Remember that the client works on a FIFO pipeline.

If you need to actually see which tasks the client will run next, invoke rr_simulation along with cpu_sched_deug in the Event Log.


I see no evidence of a FIFO pipeline. If you lower the priority of a project, it will leave those tasks half done and start different ones.

The point is it's not very intelligent at all as to what runs when. What would simplify it is to only apply project weights at one point - when they're downloaded. It seems to be doing it a second time when it picks one to run. An extreme example:

Set MW to weighting 1000. Set Einstein to weighting 1.
Boinc will download MW most of the time, but every so often it will get some Einstein. But since 1/1001 of the time adds up to running one task every blue moon, Boinc will hardly touch that task until it gets close to the deadline. Then at the very last minute it will start it, only to find you've shut the machine off, or are playing a game, or it misjudges the time remaining, so it gets returned late.


There's no winning no matter which way you choose...ie your way or if you chose to have it set to run immediately upon downloading it stops whatever else you are doing and runs to completion meaning you lose out on that special badge or bunkering event because it needed that 1% workunit. The point is Boinc has no clue you want to watch a movie tomorrow night or compete in that event or shut down the pc because it's roasting hot or you are going out of town or whatever, it's a computer not an AI.


It knows how often the computer is switched off or placed into pause due to a game etc. It should therefore know not to start a 3 hour remaining task 4 hours before the end, in case I play the same game for 5 hours I played the whole of the last week! Even putting user interaction aside, it's only a predicted remaining time, Boinc can get it very wrong, so it should leave a much wider margin of error.

Anyway, my way above would work fine. Let's say you choose weightings of 1 and 1000. It should download 1 task from project A and 1000 from project B before getting another A, but once it has downloaded them just run them.
7) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70110)
Posted 4 Sep 2020 by Peter Hucker
Post:
You are confusing task deadline and resource shares for the needs of the REC scheduler. You need to read up on that. The REC scheduler is the next highest arbiter of which tasks should run after task deadlines. Remember that the client works on a FIFO pipeline.

If you need to actually see which tasks the client will run next, invoke rr_simulation along with cpu_sched_deug in the Event Log.


I see no evidence of a FIFO pipeline. If you lower the priority of a project, it will leave those tasks half done and start different ones.

The point is it's not very intelligent at all as to what runs when. What would simplify it is to only apply project weights at one point - when they're downloaded. It seems to be doing it a second time when it picks one to run. An extreme example:

Set MW to weighting 1000. Set Einstein to weighting 1.
Boinc will download MW most of the time, but every so often it will get some Einstein. But since 1/1001 of the time adds up to running one task every blue moon, Boinc will hardly touch that task until it gets close to the deadline. Then at the very last minute it will start it, only to find you've shut the machine off, or are playing a game, or it misjudges the time remaining, so it gets returned late.
8) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70106)
Posted 3 Sep 2020 by Peter Hucker
Post:
Check how much cpu support is needed for each task type and make sure you have enough. Having only half of the load on a card with 0.5 share should only be transitional. It is making room to allow the full gpu tasks to start based on the REC needs. I have run both Einstein, Milkyway and GPUGrid on my cards with 0.5 shares for both Einstein and Milkyway and 1.0 share for GPUGrid and the cards and the scheduler behaved themselves. Many times I would have a Einstein and a Milkyway running on a card together with no issues. Only when a GPUGrid task was queued to run next did one of the 0.5 tasks drop off and none to replace it because the scheduler knew the GPUGrid task was next up.


I've set all GPU tasks to "need" 0.01 cores of CPU, since they get a higher process priority in Windows and always shove CPU tasks out of the way automatically (I've tested it).

It's not being sensible at all.
If the full gpu tasks are more important, it should do those and stop the half ones immediately.
If the half gpu tasks are more important, it should either download more of them, or run a full GPU task for a bit to reduce the buffer size.

Also, since I had some more half GPU tasks sat waiting, it might as well have those running aswell! It would be like you and me having a big heavy job to do, say moving a sofa, which requires us both. Also we each have some smaller jobs to do. You decide one of yours is very important and go do that, and the way Boinc works, I'd sit and wait instead of doing something I have which is less important than the sofa.
9) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70103)
Posted 3 Sep 2020 by Peter Hucker
Post:
How will this make it better? Twice the effort going into 64 bit? Less untidy programming catering for both?


If they actually revisit the codebase and remove all the workarounds and jumps to handle 32 bit code, it would reduce the size of the applications and possibly speed them up.
Mainly talking about the BOINC applications like the client and the manager. The science apps are a different story. They said a long time ago that the 32 bit science apps are faster than the equivalent 64 bit app in some cases because the memory access is simpler.


They also need to rewrite the scheduler. I've yet again got something stupid happening here.

I have Collatz set to run 1 WU per GPU, Einstein to run 2 per GPU, and Milkyway to run 2 per GPU (because that's what it's most efficient at).

Normally this works fine, but I've just noticed it being daft. It's running the last Einstein in it's queue on half the GPU. It's got Collatz and Milkyway queued. But it's refusing to shove the Milkyways into the other half of the GPU. I can only assume because I have Collatz at higher priority, so it wants to run that. But it won't move Einstein out because that's also a fairly high priority. Half the GPU is idling! Anybody got a common sense stick?
10) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70096)
Posted 31 Aug 2020 by Peter Hucker
Post:
The capabilities of the graphics cards are read from the vendors API stack. For our use that is either the CUDA API or the OpenCL API depending on which vendor the science applications use.

Already at a disadvantage on the memory capacity with Nvidia cards as mentioned previously because of incorrect API usage. And at the low level, each card is still restricted by the silicon and gpu firmware installed. You will never get a OpenCL 1.0 capable card perform a OpenCL 1.2 or 2.0 instruction.


So who is responsible for Einstein Gravity trying to run on my R9 280X cards and failing? Has the card misreported it can do it? Or is Einstein not properly checking?
11) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70086)
Posted 30 Aug 2020 by Peter Hucker
Post:
According to the Developers there is ALOT of 32bit crap in there holding things back, ie showing the actual amount of memory on gpu's that have more than 4gb so projects can filter then out of app that crash when trying to run them, ie Einstein. The 64bit stuff is already in there, making one without the 32bit stuff in it has been in the works for awhile to make sure Boinc still works afterwards.


It's not just the memory they need to filter on, I've got cards with plenty memory that won't run gravity, because they lack the newer instruction set. What they should be doing is looking at the model of graphics card, and comparing it to a list of ones that the program has been tested on. Or just testing for certain instructions being available. I notice when you start Boinc that it has a big list of AVX, MMX, etc for CPUs. Does it check cards like that too?
12) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70085)
Posted 30 Aug 2020 by Peter Hucker
Post:
Talking about two DIFFERENT things here. Boinc apps are NOT the science apps.


I know. I thought you or someone else mentioned they were planning on stopping the 32bit science apps too.
13) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70080)
Posted 29 Aug 2020 by Peter Hucker
Post:
How will this make it better? Twice the effort going into 64 bit? Less untidy programming catering for both?


If they actually revisit the codebase and remove all the workarounds and jumps to handle 32 bit code, it would reduce the size of the applications and possibly speed them up.
Mainly talking about the BOINC applications like the client and the manager. The science apps are a different story. They said a long time ago that the 32 bit science apps are faster than the equivalent 64 bit app in some cases because the memory access is simpler.


Surely we should continue using both if it's not a one size fits all?
14) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70075)
Posted 29 Aug 2020 by Peter Hucker
Post:
No, they are just dropping all the x86 32 bit versions.


What did you mean by "Hopefully with the totally 64 bit versions coming it will be a lot better"?

Oh, sorry, two of you in here now. The other guy! Oy you! What did you mean by the above?


Simple no more 32 bit versions of Boinc will be written and all future version will be 64 bit ONLY!! They are removing ALL the 32 bit legacy stuff from the client side, that's us, software. I have no clue if they are doing the same to the server side or not but ALOT of projects are dumping 32 bit apps going forward. They will continue to provide Pi and Droid stuff but not 32 bit computer stuff. A few projects have already done it while others are analying the 32 bit usage percentage at their projects, those that have reported the results have said it's under 5% now.


How will this make it better? Twice the effort going into 64 bit? Less untidy programming catering for both?
15) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70063)
Posted 28 Aug 2020 by Peter Hucker
Post:
No, they are just dropping all the x86 32 bit versions.


What did you mean by "Hopefully with the totally 64 bit versions coming it will be a lot better"?

Oh, sorry, two of you in here now. The other guy! Oy you! What did you mean by the above?
16) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70061)
Posted 28 Aug 2020 by Peter Hucker
Post:
As Trump says 'it is what it is' and we all have to deal with it. Hopefully with the totally 64 bit versions coming it will be alot better.


Boinc is being totally rewritten?
17) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70058)
Posted 27 Aug 2020 by Peter Hucker
Post:
The software for the Boinc Server is soooo generic and setup for how Seti does things that changes are required if you want to run any other project, change an Admin or two over the years and how and what changes are made are lost.


Looks like the server software needs re-doing aswell as the client.


You are a real dreamer aren't you... :-) You do know Dr A is in charge of that too...right?


If Boinc was commercial it would have gone out of business.


It's always been free, it was designed that way in the very first paper written for the funding to create it.


I know, I was just pointing out how many bugs are in it. Imagine a big company like Microsoft releasing an OS with er.... I've forgotten my point.
18) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70056)
Posted 27 Aug 2020 by Peter Hucker
Post:
The software for the Boinc Server is soooo generic and setup for how Seti does things that changes are required if you want to run any other project, change an Admin or two over the years and how and what changes are made are lost.


Looks like the server software needs re-doing aswell as the client.


You are a real dreamer aren't you... :-) You do know Dr A is in charge of that too...right?


If Boinc was commercial it would have gone out of business.
19) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70053)
Posted 26 Aug 2020 by Peter Hucker
Post:
Load up a 2nd Boinc in a seperate folder and setup 2 venues, one for the gpu and one for the cpu's, excluding the gpu in the one you want cpu tasks and vice versa in the other instance of Boinc.


Excellent idea. I might try that if I can be bothered, seems like a lot of hassle though. Especially when they could fix it on the server end. But we all know they never do things like that here.


LOTS of Projects are what they are, free programing help is easy to come by but GOOD and FREE programming help is hard to find. Sure they could ask as there are resources if they wanted to take advantage of them but it seems they don't wish too.


I'm not sure why they need to program anything. There's this program called Boinc server, right? You just tell it how you want your project set up, the programming is already done. In Milkyway's case, the GPU version of Seperation should be classed as a seperate app, like it is in Einstein, then WUs could be sent to the correct chips. And god knows how they managed to break the server's ability to upload and download workunits at once.


The software for the Boinc Server is soooo generic and setup for how Seti does things that changes are required if you want to run any other project, change an Admin or two over the years and how and what changes are made are lost.


Looks like the server software needs re-doing aswell as the client.
20) Message boards : Number crunching : Twin CPUs and multi-core nbody tasks - success :-) (Message 70051)
Posted 25 Aug 2020 by Peter Hucker
Post:
Load up a 2nd Boinc in a seperate folder and setup 2 venues, one for the gpu and one for the cpu's, excluding the gpu in the one you want cpu tasks and vice versa in the other instance of Boinc.


Excellent idea. I might try that if I can be bothered, seems like a lot of hassle though. Especially when they could fix it on the server end. But we all know they never do things like that here.


LOTS of Projects are what they are, free programing help is easy to come by but GOOD and FREE programming help is hard to find. Sure they could ask as there are resources if they wanted to take advantage of them but it seems they don't wish too.


I'm not sure why they need to program anything. There's this program called Boinc server, right? You just tell it how you want your project set up, the programming is already done. In Milkyway's case, the GPU version of Seperation should be classed as a seperate app, like it is in Einstein, then WUs could be sent to the correct chips. And god knows how they managed to break the server's ability to upload and download workunits at once.


Next 20

©2021 Astroinformatics Group