Einstein GPU WUs utilisation issue and Wish List forum credit wall
23 Sep 2014 13:45:05 UTC
Topic 197731
(moderation:
I have one Problem running Einstein GPU Workunits and since about one year nothing changed, so i decided to ask about it.
I have testet this only with ATI/AMD Cards, Win 7 and Intel CPU. (I'm pretty sure the CPU has no part in this, but who knows)
If i run BRP4G for example (but afaik every gpu project from einstein suffers from that) and full load on every core the GPU does just nothing. No load, no heat, no power consumption. Maybe some little spikes every minute.
Milkyway or Poem for example run fine like that.
I try to pin every GPU Workunit to exactly one core, so that no corehopping happens.
If i make the einstein WUs run on Realtime(!) priority they run fine at ~87% GPU load while the CPU WUs don't suffer much. Even high priority does not help, it has to be Realtime.
Unfortunately that causes nasty lags here and there, making watching videos or browsing quite uncomfortable, sometimes i can't even hear music while such a supported einstein WU is running because the stupid scheduler seems to put some process in the audio chain on the last core where a CPU WU and this einstein GPU WU is running.
I don't know what you are doing wrong, or what the other projects just make differently. But i bet it would be worth knowing. For me this Problem is the Reason why i stopped crunching for Einstein, it is already complicated enough to manage boinc to reduce workload if i want to play some games, i don't want to stop specific projects if i want to listen to some music or something.
Hardware/Software used:
AMD 7870 with Pitcairn chip (Tahiti LE version had the same problem)
core i5 3570K
Win7
on CPU WCG Workunits
process lasso to manage custom priority and affinity settings
My second, smaller, problem was that i was unable to create a thread in the Wish List forum. It said i need some credits to do that. Just how many has one to have to do that? I have got 11,525,729 atm, several years of crunching, but still not enough to create an entry in the Wish List forum. I feel like there went something wrong.
Einstein GPU WUs utilisation issue and Wish List forum credit wa
)
Your RAC shows here as zero, apparently rounded down to that from 0.13. BOINCstats suggests you have not earned any Einstein credit in the last forty days. It seems you just resumed downloading work on September 23 after several months break. Quite possibly there is a wish list requirement imposed to open the door to currently active participants.
Most of us find it helpful in running the Einstein GPU work to adjust our compute preferences to reduce the fraction of available CPU cores which BOINC attempts to use to less than 100%.
Quite commonly this gives more total Einstein work output. In your specific case, it might help you better to survive the extreme priority you have chosen to apply to the GPU Einstein support process.
Your experiment in obtaining poor user interactive performance by altering the default process priorities may perhaps help you see why the default priorities are set very low. It has always been the general intention of BOINC work to allow donation of "spare" capacity with little impairment of other system use.
Process Lasso can be a useful tool (it runs on three of my hosts), but it is also very easy to do great harm with it. You need really good evidence that a particular modification of affinity or priority is actually helpful to the performance outcomes you care about. I think actual experimentation with careful assessment of outcomes is likely to do better than forcing configurations to ones which one "just knows" ought to work better. I have worked in computers for decades, yet I have often surprised to find the outcome of a particular Process Lasso intervention to have quite a different result than I predicted.
I believe the problem is a
)
I believe the problem is a combination of how the graphics driver work in regards to OpenCL workloads and what data is analyzed and the methods used to analyze this data. So the experience can differ from project to project.
The general consensus on this project is that any processing using OpenCL "requires a free CPU core" to support it. So as archae86 said try to reduce the number of CPU tasks that run while running OpenCL tasks from Einstein. If you do you won't have to set the process priority to "above normal" to get good load on the GPU.
This can be done by either setting the prefs to restrict Boinc to not use all cores but that will always apply. It can also be done by using a app_config.xml file to dynamically reduce the CPU tasks when Einstein GPU work runs.
To use a app_config.xml then open a new document in Notepad and copy the following into it:
[pre]
einsteinbinary_BRP4
1
1
einsteinbinary_BRP4G
0.5
0.5
einsteinbinary_BRP5
0.5
0.5
[/pre]
Then save the file to the einstein.phys.uwm.edu subfolder of the Boinc data folder. The default on Win7x64 is a hidden folder with the following path C:\ProgramData\Boinc\projects\einstein.phys.uwm.edu
Make sure you save it as exactly app_config.xml and that it does not get a .txt extension. If done right then Boinc's event log should show the following line when choosing Advanced -> Read config files:
23/09/2014 17:34:21 | Einstein@Home | Found app_config.xml
The above file should get you running one task on a Intel GPU with on CPU core reserved and two BRP4G or BRP5 tasks or one of each on the AMD card with one CPU core reserved for 2 tasks. The CPU core reservations will only be in effect when GPU tasks from Einstein is running.
As to you not being able to post in the "Wish List" it's a spam protection that requires anyone to have a RAC of at least 1 to be able to post in any forum other than "Problems and Bug Reports".
Edit to fix typo, thanks archae!
Holmis wrote: Make sure you
)
typo there, instead of fonfig try config.
Of course it would work if i
)
Of course it would work if i just leave one core free for gpu work, but why? Beside some 'luxury problems' (is there such phrase in english?) like unusual core temperatures that will irritate me i just don't want to have one core nearly idle just because a gpu project is not cycle hungry enough. In fact i can't even imagine why it just stops working if the core is not free or it is running in realtime priority. But i'm not used to programming using a gpu.
As for crunching i want my cpu busy if i don't need it. It's additionally stability testing and system monitoring. If the temperatures change, something happened. Besides, it would mean to lower the output of the CPU by 25%. So i don't want to do that if the GPU project not even uses 4% of that core. To have 1% of the CPU power usable i would have to let 24% idling. Thats just inefficient.
I suppose that this maybe can be solved by optimisation, also the einstein projects put considerable less load on the gpu, even with a free core or realtime priority than milkyway or poem. But this is just a wish of mine. Some optimisations and a easy running WU for my GPU that does not need such problematic special treatment like a free core for nearly nothing or realtime priority and that uses the gpu a little bit more efficiently and therefore faster crunching.
Also my PC is unusual cold while running einstein instead of milkyway, i get unsure about the room temperature every time i see the hardware temps until i realise that i'm not freezing and the window is closed.
RE: i can't even imagine
)
In case someone drops by who is curious on this point, the answer is pretty simple.
Progress on the Einstein GPU computation (as with other GPU computations) requires services provided by the CPU. Some of these are essentially data movement, while others are computation, probably computation that is not a good fit to the rather specialized resources present on the GPU--which are wonderful at what they do well, and remarkably bad at some other things.
While to a limited degree running more than one Einstein task on the GPU can give it something else to do, if CPU service is not forthcoming, it will very, very rapidly run out of available work.
So the complete set of other tasks running on the system CPU, their critical section structure (i.e. how much of the time they refuse interrupts necessary for task-switching), their priorities, and such, help govern in concert with the scheduling scheme adopted by the OS in use how long the GPU sits waiting for CPU service.
Even if the GPU servicing task get a pre-emptive priority allowing it to bump the currently executing task from a core, there is task switch overhead which constitutes a latency penalty, compared to the ideal case.
Just to give a simple example, if someone has adjusted default priorities and affinities on their machine in such a way that the only allowed core(s) for the GPU support task currently have higher priority tasks running on them, the GPU would sit waiting until that task does some I/O so that gets it bumped off. If there are are pending higher priority tasks, then even in that case the GPU servicing task won't get CPU cycles.
As it appears that Bigeagle is not here to seek assistance in running an Einstein host efficiently, but is rather here to voice annoyance at the behavior of the Einstein applications on his system, I'll desist from further attempts at assistance.
Sorry if i did not make it
)
Sorry if i did not make it clear that i don't just want let one core idle for gpu work, but to express my wish that it would run without the need to do that.
The ideal case would be that i just pin the gpu work on one core (yes, that gives at least in all projects i have tested so far a clear boost in performance) and set the priority to lets say normal while the CPU tasks run at 'idle' priority.
It's something that would have to be done in the source code i would assume. Thats why i wanted to post this in the wish list.
If it is not possible to do that because of the very latency sensible workload then it can't be changed. But i wanted to ask, because i know others that stopped running einstein because of such problems while other projects run fine.