No work received for a long time
29 Oct 2015 8:48:20 UTC
Topic 198289
(moderation:
Hi,
Up until a few weeks ago I was receiving plenty of work on a regular basis, but it suddenly stopped and I haven't been sent any work at all. I haven't changed any of my computer's settings and all the possible reasons as listed on the FAQs page don't seem to apply.
Any suggestions? Happy to provide whatever info is needed!
No work received for a long time
)
In your Einstein@home preferences what have you selected for "Run only the selected applications"?
Currently there is work available for "Binary Radio Pulsar Search (Parkes PMPS XT)" (BRP6) for your GPU and "Gamma-ray pulsar search #4" (FGRP4) for your CPU.
The last contact log for host 8651045 shows it not requesting work, check in Boinc manager that you haven't accidentally set Einstein@home to "No new work".
Hi Holmis! In
)
Hi Holmis!
In Einstein@home preferences it shows "Run only the selected applications (all applications)"
The BOINC manager shows that "no new tasks" is not selected for this - or any other - project.
I might try reinstalling BOINC at the weekend and see if that makes any difference.
how are your resources
)
how are your resources shared? What is the setting for each project?
Have you notice if 1 project seems to run more than the other?
Have you tried suspending the other projects and see if Einstein then request work?
Hi Zalster! First the bad
)
Hi Zalster!
First the bad news. I actually reinstalled BOINC this evening and it made no difference :-(
Now the good news. Suspending all the other projects resulted in BOINC downloading three Binary Radio Pulsar tasks and two Gamma-ray pulsar tasks! This would appear to be a work around the problem but I don't want to have to manually suspend all the other projects every time I want Einstein to grab more work.
Each project's resource share is set to 100, so they get 20% each. This is the way it's always been! Very odd...
Ok, I think you have
)
Ok,
I think you have figured out the problem there. Some projects figured out that if they place a higher priority (shorter time to complete) on their work units, they can basically take control of the computers.
This is especially true if each project is 100%.
I end up doing just what you do, I suspend 1 project and let it crunch for a while, then suspend this and allow work to start on the other.
Unfortunately, that is the only way I have found to run more than 1 project at a time.
Not all projects do this but a good many do so that it's fairly common.
Happy Crunching...
Zalster
Appreciate your help. It's
)
Appreciate your help.
It's just a bit strange that all five projects I run would co-exist quite happily up until a few weeks ago. Still, there you go :-)
RE: ... Some projects
)
I wonder if these 'projects' have lawyers on their payroll? You might find yourself getting sued :-).
Seriously, I suspect the only projects playing 'unfairly' are those that offer ridiculous credits in order to attract participants. The ones that the OP has joined don't appear to be in that category. Some may have shorter duration deadlines than Einstein but that doesn't mean the work is immediately placed in some mythical higher priority queue that the project can control. BOINC is in charge of deciding what work needs high priority mode (panic mode) and if the user chooses a suitable work cache setting and runs the computer reasonably consistently ( ie doesn't turn it off for long periods - many days or weeks) BOINC should be able to manage the work flow without resorting to panic mode.
The real reason why the computer wasn't getting Einstein work is probably much more prosaic - BOINC was probably allowing other projects to catch up with their fair share. I don't know all the projects on the OP's list, but most of them have outages or shortages of work from time to time. If other projects can't supply work when requested, BOINC will always turn to any one that can. because Einstein is virtually always able to supply, it is very easy for this project to get well ahead of its fair share. When other projects can supply, BOINC will try to catch them up. During those 'catch up' times, there may be quite extended periods where BOINC doesn't request Einstein work.
Only the OP can really know what's going on and only if some research is done. The BOINC data directory contains 'job logs' for each attached project. By parsing each project's job log, you could work out exactly how many tasks and how much crunch time has been devoted to each project. Unless you have scripting skills, this isn't a trivial task. One simpler thing that could be done with these logs would be to look for periods where entries were not being added - ie, time gaps where tasks were not available from that particular project. If all the other projects had overlapping time gaps, you could assume Einstein was 'having a ball' during those times and hence is not getting work now.
I'm not at all suggesting that the OP needs to do any of this. Now that it's obvious that work can be 'forced' to come from Einstein, there is no misconfiguration and BOINC can safely be left to manage things on its own. If the OP wants to see more regular Einstein work, just give it a higher resource share (eg 200 instead of 100 like all the others) so that BOINC will not be so keen to turn of the supply for long periods.
I think you mean 20%. 5 projects each at the same resource share value means that each one has a 20% share. In any case, what evidence do you have for this statement?
You would actually make the symptoms worse if you had unequal shares and the lowest share project just happened to be the highest reliability one. BOINC would just about always have that project 'off limits'. If you think about it, if you could predict the reliability of each project (good luck with that) you could set the resource shares in line with those reliabilities. This would tend to make BOINC's job somewhat easier. At the end of the day, equal resource shares is probably the best option if you 'value' all projects equally. If you favour one project, give it a higher number but keep all the others equal in their shares. Highly unequal shares are more likely to have BOINC in panic mode more often. That's when stupid things can happen. You get much smoother operation if you can keep BOINC out of panic mode.
Cheers,
Gary.
RE: ... if the user
)
What I have to say is a bit a sidestep and does not help Steve but is probably of general interest.
We let dance 4 PCs around the clock (forget the fifth one which does not work the right way at the moment, but it's place is some 80 miles far away in another country - yes, Switzerland is a very small spot on the map - and the person behind is not able to manage it; we will travel over there next week to roll the ball up to the hill again, hoping for non-Sisyphus-work :-). All four PCs are doing hard work on BRP6 beta 1.57 (GPUs, 4 tasks each) and FGRP4-SSE2 (CPU). Burned children shy away from the fire so the caches were set to 5-7 working days. A day I noticed a remarkable decreasing of RAC (Recent Average Credit) on two hosts. The second graphic cards were running only one task (instead of 4) with the result of low GPU usage. BOINC had obviously a problem with managing such a large worklist, some of the CPU tasks came in panic (lovingly called panic mode :-) and BOINC decided to prioritize FGRP4 tasks so there was not enough CPU capacity for managing of the GPU tasks. Tinkering with "use at most % of the CPUs" did not help, but temporarily suspending a couple of CPU tasks (FGRP4s with the longest expiration date) and simultaneously reducing the caches a bit was definitively successful !
Happy crunching,
Arthur
I know I am a part of a story that starts long before I can remember and continues long beyond when anyone will remember me [Danny Hillis, Long Now]