There is also a problem with GammaRayPulsarSearch#1 0.23
This client assigns itself "high priority" causing other (non-Einstein) clients to halt until GammaRayPulsarSearch#1 0.23 has completed.
At one time a 6 core processor had only 1 such GammaRayPulsarSearch#1 0.23 running while 5 other (non-Einstein) clients were put on hold, despite the 5 cores idling along.
If you are the programmer of that client and think this is the way to get the job done. Good luck. I just deleted your work units and stopped boinc from obtaining any others, Also as soon as the other Einstein clients have completed I will detach my computers from Einstein@home altogether.
If you don't know how to make your programs run as unobtrusive and well-behaved clients. You are not running on my computers anymore.
Gamma-ray pulsars units work in normal mode on my 2-cores Opteron 1210,together with other 5 projects, including Test4Theory@home, which runs on a VirtualMachine. The only project running high priority on a core is climateprediction.net, so I have to suspend it at intervals. But the other core is used regularly.
Tullio
There is also a problem with GammaRayPulsarSearch#1 0.23
This client assigns itself "high priority" causing other (non-Einstein) clients to halt until GammaRayPulsarSearch#1 0.23 has completed.
At one time a 6 core processor had only 1 such GammaRayPulsarSearch#1 0.23 running while 5 other (non-Einstein) clients were put on hold, despite the 5 cores idling along.
If you are the programmer of that client and think this is the way to get the job done. Good luck. I just deleted your work units and stopped boinc from obtaining any others, Also as soon as the other Einstein clients have completed I will detach my computers from Einstein@home altogether.
If you don't know how to make your programs run as unobtrusive and well-behaved clients. You are not running on my computers anymore.
Boinc is the client, not the GammaRayPulsarSearch#1 0.23 application, and it is Boinc that will decide to run an application in high priority, not the GammaRayPulsarSearch#1 0.23 application,
Why not upgrade to the Current Recommended version, that being 6.12.34 for Linux x86 and x64, Boinc 6.10.59 i believe was a one off client that never made recommended for Linux.
There is also a problem with GammaRayPulsarSearch#1 0.23
There is no such 'problem' of the type you allude to, with that science application. As Claggy correctly points out, it's entirely up to BOINC as to how tasks are scheduled to run (and at what priority) on your computer. It's not possible for a simple, single threaded science app to 'hog' more than one core of your 6-core host, while crunching a single task. The app cannot cause 5 cores to be idle, period. If you really did have 'ready-to-run' tasks and idle cores, it would have to be a BOINC problem and you should investigate all your BOINC settings and preferences. It's nothing to do with the individual science app.
Quote:
If you don't know how to make your programs run as unobtrusive and well-behaved clients. You are not running on my computers anymore.
I can fully understand your frustration if BOINC is not behaving the way you would like it to on your computer. I'm surprised you think that insulting the intelligence and competence of the programmer who wrote the science app code is a good way to tackle the issue. It might help your frustration but it's quite likely to get you ignored. I'm responding, only because I suspect you may be able to have a much less frustrating experience if you think through how your BOINC preferences work. You need to consider some of the difficulties for BOINC to do what you want if some of the projects in your mix are unable to supply work from time to time. Coupled with this, how you allocate resource shares and the size of the work cache that you choose can make it virtually impossible for BOINC to cope without resorting to running various tasks in high priority mode most of the time.
I'm guessing that Seti is your main project and that you use E@H essentially as a backup. It's fine to do this but you need to be careful with your settings, particularly work cache days. If you have a lot of days and Seti can't supply work, BOINC will fill those days from projects that can. When Seti can supply work, BOINC will then have a problem disposing of the excess backup work that it has acquired. This will be even worse if the backup project has a low resource share.
You haven't given enough information to know for sure and I have no idea of how Seti is going of late but if you think the problem might be something to do with recent Seti outages, just let us know what you are using for resource shares, work cache days, if you are running 24/7 or not, etc, and I'd be happy to give suggestions on how you might be able to stop BOINC getting too much backup work, particularly short deadline backup work which is much more likely to trigger BOINC into using high priority unnecessarily.
There is also a problem with
)
There is also a problem with GammaRayPulsarSearch#1 0.23
This client assigns itself "high priority" causing other (non-Einstein) clients to halt until GammaRayPulsarSearch#1 0.23 has completed.
At one time a 6 core processor had only 1 such GammaRayPulsarSearch#1 0.23 running while 5 other (non-Einstein) clients were put on hold, despite the 5 cores idling along.
If you are the programmer of that client and think this is the way to get the job done. Good luck. I just deleted your work units and stopped boinc from obtaining any others, Also as soon as the other Einstein clients have completed I will detach my computers from Einstein@home altogether.
If you don't know how to make your programs run as unobtrusive and well-behaved clients. You are not running on my computers anymore.
Gamma-ray pulsars units work
)
Gamma-ray pulsars units work in normal mode on my 2-cores Opteron 1210,together with other 5 projects, including Test4Theory@home, which runs on a VirtualMachine. The only project running high priority on a core is climateprediction.net, so I have to suspend it at intervals. But the other core is used regularly.
Tullio
RE: There is also a problem
)
Boinc is the client, not the GammaRayPulsarSearch#1 0.23 application, and it is Boinc that will decide to run an application in high priority, not the GammaRayPulsarSearch#1 0.23 application,
Why not upgrade to the Current Recommended version, that being 6.12.34 for Linux x86 and x64, Boinc 6.10.59 i believe was a one off client that never made recommended for Linux.
Claggy
RE: There is also a problem
)
There is no such 'problem' of the type you allude to, with that science application. As Claggy correctly points out, it's entirely up to BOINC as to how tasks are scheduled to run (and at what priority) on your computer. It's not possible for a simple, single threaded science app to 'hog' more than one core of your 6-core host, while crunching a single task. The app cannot cause 5 cores to be idle, period. If you really did have 'ready-to-run' tasks and idle cores, it would have to be a BOINC problem and you should investigate all your BOINC settings and preferences. It's nothing to do with the individual science app.
I can fully understand your frustration if BOINC is not behaving the way you would like it to on your computer. I'm surprised you think that insulting the intelligence and competence of the programmer who wrote the science app code is a good way to tackle the issue. It might help your frustration but it's quite likely to get you ignored. I'm responding, only because I suspect you may be able to have a much less frustrating experience if you think through how your BOINC preferences work. You need to consider some of the difficulties for BOINC to do what you want if some of the projects in your mix are unable to supply work from time to time. Coupled with this, how you allocate resource shares and the size of the work cache that you choose can make it virtually impossible for BOINC to cope without resorting to running various tasks in high priority mode most of the time.
I'm guessing that Seti is your main project and that you use E@H essentially as a backup. It's fine to do this but you need to be careful with your settings, particularly work cache days. If you have a lot of days and Seti can't supply work, BOINC will fill those days from projects that can. When Seti can supply work, BOINC will then have a problem disposing of the excess backup work that it has acquired. This will be even worse if the backup project has a low resource share.
You haven't given enough information to know for sure and I have no idea of how Seti is going of late but if you think the problem might be something to do with recent Seti outages, just let us know what you are using for resource shares, work cache days, if you are running 24/7 or not, etc, and I'd be happy to give suggestions on how you might be able to stop BOINC getting too much backup work, particularly short deadline backup work which is much more likely to trigger BOINC into using high priority unnecessarily.
Cheers,
Gary.