Hi there,

Since the thread on 6.14 is closed I post it here.
"http://www.gpugrid.net/forum_thread.php?id=2545"

Could you give me an update on the issue's with the new higher priority with the 6.14 tasks?

In a case of great timing I switched to Einstein@home at the time the new tasks came out, so did not notice it back then. Just switched back to GPUGRID to find an extremely sluggish response from all running applications.

Currently dropped all GPUGRID tasks and switched back again to Einstein.


You made a mistake with the above normal priority, thats ok no problem. Been there, done that ;).

But when can we expect new tasks with a correct priority (idle or below normal) that does not prevent any user run application from functioning?

Thanks,

You can solve this problem with a 3rd party priority changer tool. See this message.

I know I can manually set the priority back to something lower, and yes there are tools that you can use to automate it. But that is not a solution to the problem, merely a workaround.

A workaround a participant/volunteer or whatever you wish to name the people running GPUGRID should not have to use.


Using the above normal priority goes against the main principal of all distributed computing projects, the usage of idle/unused computing power. This is fine if you have dedicated machines solely running GPUGRID but not for regular situations.


Sure the setting will ensure a higher performance, simply by making sure GPUGRID takes priority over all other applications except a few OS processes. Then make it a recommendation for those users with a dedicated machine not running anything else to set this by hand or 3rd party tool in the FAQ: Best configurations for GPUGRID. The way it is now is just wrong

I agree with Qazwaplol. Setting the priority higher than idle or below normal is wrong. It defys the basic BOINC philosophy of using spare CPU cycles and it's a blatant hijacking of resources. People who install BOINC do so on the assumption that only spare cycles will be used because that's how BOINC is advertised at the BOINC website and everywhere else. For GPUgrid to do otherwise is a fraud and abuse of the trust of volunteers.

As Qazwaplol said, those who want the task to run with higher priority can do so via third party software. Volunteers running dedicated crunchers don't need to do anything since the task(s) will get nearly all the CPU time anyway.

The more I learn about this project the less I like it. There is also the problem with WUs being resent before the 5 day deadline passes.

To those of you who say GPUgrid is not the right project for me I say no, GPUgrid is not right for BOINC.

While I do agree with both of you to some extent, I have to note that there was a beta testing phase with above normal priority, and no such problems were reported. That's why it went to production phase, then complaints showed up. To fix this, in the future the priority class will be set differently on the GPU attached to the display. BTW it should have been done by now.

While I do agree with both of you to some extent, I have to note that there was a beta testing phase with above normal priority, and no such problems were reported. That's why it went to production phase, then complaints showed up. To fix this, in the future the priority class will be set differently on the GPU attached to the display. BTW it should have been done by now.

It is necessary for GPU tasks to run at some level above low.

There is also the problem with WUs being resent before the 5 day deadline passes.

This was changed from 2days to 3days to please the masses, including you.

There is an arguement to say that GPUGrid would be better off with it's own manager, but for different reasons (Settings mostly); the same CPU tasks could still interfeer with the GPU tasks if they were controlled by different managers.

As I explained in previous posts the project is now in high production mode rather than development mode.

I seem to recall that I read on the mailing list that this priority issue would be fixed when GDF comes back. Is this true? When does he come back?

And yeah, the re-issue and due dates should always be the same. It's not fair to tell someone that they have 5 days (for example) to return a task, and then re-issue it earlier. It sets them up to not get awarded credit. Not to mention a waste of time and energy.
____________
Reno, NV
Team: SETI.USA

I would have given your post a plus Dagorath but they have disabled that capability.

You are of course correct with all the points you make about playing by the rules of BOINC.

I personally, am getting fed up of changing priority on the 6.14 app and a lot of people will be put off by it affecting the performance of their computer so it will all end in loss of active members and any increase in performance will be more than negated.

The main point i would like to make is that I find the 6.14 app significantly faster even with priority set to below normal thus making such a change unnecessary.

I understand that most computers are bady configured and working below their potential, however, these systems usually belong to people who know nothing of process priorities or computers and more to the point, don't want to know. It is wrong to mess with priorities to obtain more resource from these already sub-optimal machines.

I also think the proposed fix is wrong, that is to only lower the priority of WU's running on device-0. I think this will also come back and bite GPUG in the ass.

This is already a small project in BOINC terms and that should tell the developers something. The people running this project long term have knowledge of their systems, many with multiple graphics cards. These people will actively get the best performace out of their machines either because they know how or will find out how by visiting fora and asking questions.

The devolopers of this project need to make what they want clear.

1) What is the lowest card (and driver version) allowed, notice I say allowed not recommended.
2) One clear deadline.
3) HT, on/off, because most people use HT to get more throughput on cpu projects or simply because it was on by default and don't realise the pro's and con's of HT. A 4 core processor running 8 projects will obviously become "cache and bus bound" and slow down the machine.

When people know what you expect they'll either join or not.

Please remember this is an elite project requiring investment in the higher end cards and systems, not a £399 machine bought from PC World with integrated graphics and cheap components which, do not always have PCI-E expansion slots to upgrade graphics even if they wanted to.

I could go on but you can see where this is going.

Know your users/potential users and their machines.

EDIT TO ADD

It is pitiful that I, with such a small contribution can be ranked 67th highest user. This should also tell you something. Get your act together GPUG.

If this post sounds overly aggresive to some I'm sorry but like Dagorath (I think) I hate wooly thinking and compromise which leads to misunderstanding and disappointment.
____________
Radio Caroline, the world's most famous offshore pirate radio station.
Great music since April 1964. Support Radio Caroline Team -
Radio Caroline

Many projects run GPU tasks at higher priority. Since the apps use very little CPU this allows complete GPU utilization and still uses almost no CPU time. Boosting priority on some GPU apps allows them to run at 99% GPU while still using negligible CPU and still allowing a responsive system. Of course as always YMMV depending on what other apps are running and on the skill of the GPU app programmer.

Thanks GDF

well i didnt read all the posts but to say gpugrid isnt right for boinc, i think you should consider that it works for schizophrenia and so what is boinc to the 24 million schizophrenic people in the world except gpugrid.