Is there a parameter control to set run priority please?
I just downloaded brand new workunits which only have a \"life\" of 3 days, and they run immediately under High Priority. This reduces any other application to a poor second postion, so it does not get any processor time?
Thanks
Homefarm
____________
Home to the Pottage Herd of Organic Aberdeen Angus Cows
/ 
Is there a parameter control to set run priority please?
I just downloaded brand new workunits which only have a \"life\" of 3 days, and they run immediately under High Priority. This reduces any other application to a poor second postion, so it does not get any processor time?
Thanks
Homefarm
You need to reduce your \'cache\' size to something less than about 1.75 days. This is due to the way BOINC calculates which wu\'s it needs to work on to ensure the work is completed before the work unit deadline is reached. And since Malaria Control work units have always had a 3 day deadline this part isn\'t going to change.
Live long and BOINC!
____________
Paul
(S@H1 8888)
/
Thanks, will do that.
I expanded the cache when I was having BT problems, so I would not run out of work; that was Cosmology which has a longer \"shelf life\" anyway.
I moved over to Malaria Control as it seemed to have more real purpose than Seti or Cosmology, which are great but don\'t have any benefit to people who need help with disease control.
____________
Home to the Pottage Herd of Organic Aberdeen Angus Cows
/
I\'m having the same problems. I\'ve got my cache set to to 3 days and I also always get malariacontrol.net WU\'s in priority as soon as some of them are downloaded.
I don\'t want to be stubborn, but why would you not increase your deadline to a week or so? Imho it\'s a very faint excuse to say \"And since Malaria Control work units have always had a 3 day deadline this part isn\'t going to change\". I might as well say: \"Malaria has always been around, so I don\'t see any reason to get rid of it\".
So what\'s the actual reason for not extending the deadline? Maybe something like continuity so you\'d get delays in your research if you\'d extend the deadline? I can hardly believe that.
In the preferences it\'s possible to set the cache to 10 days (so my 3 days are not really that extravagant), so I think it wouldn\'t be really strange for the projects itself to also take this and their crunchers preferences into account.
Whenever I get WU\'s in priority mode I solve it by deleting every \"earliest\" WU of that project until the priority mode vanishes. This works fine as well, but it\'s not what I prefer.
Just my 2 cents.
I/I
/
I don\'t want to be stubborn, but why would you not increase your deadline to a week or so?
...
So what\'s the actual reason for not extending the deadline? Maybe something like continuity so you\'d get delays in your research if you\'d extend the deadline? I can hardly believe that.
Rather than rewrite or paraphrase what Nick wrote, I\'ll just link to it here: work creation and deadlines.
/
Rather than rewrite or paraphrase what Nick wrote, I\'ll just link to it here: work creation and deadlines.
Thanks for pointing me to the explanation. At least now I know why it is they use these short deadlines, though I\'m not yet convinced it\'s really necessary.
The explanation says the imbalances will settle out in the long term, but with me it results in many WU\'s (also of another project I\'m running in that computer, proteins, which also has not too long deadlines) not reaching their deadlines.
I like to use more than one day of cache because I\'ve had hardware failure (router/cable modem) problems in the past and it can take a couple of days to replace them, and I don\'t want to waste too many potential flops in the mean time if it would happen again. On another computer I\'ve got continuously 7 projects running without ever running into deadlines and without any of them giving me problems with my cache-size. I still don\'t understand why malariacontrol has to be so different.
If they want as much results as possible, they shouldn\'t bug their crunchers with WU-management they shouldn\'t be bothered with (that\'s what the Boinc platform is supposed to do). If they don\'t care about people with larger cache sizes than 1.75 days running into deadlines and consequently deleting WU\'s that pass the deadlines, than things are fine as they are of course. It\'s not what I like to do, but I don\'t want to decrease my cache size either, more like the other way around, still because of Malariacontol I don\'t.
Well, hopefully some day they\'ll find a solution.
Thanks for your reply anyway.
I/I
/
Thanks for pointing me to the explanation. At least now I know why it is they use these short deadlines, though I\'m not yet convinced it\'s really necessary.
:) That\'s where the project admins have to come in and convince you.
The explanation says the imbalances will settle out in the long term, but with me it results in many WU\'s (also of another project I\'m running in that computer, proteins, which also has not too long deadlines) not reaching their deadlines. If they want as much results as possible, they shouldn\'t bug their crunchers with WU-management they shouldn\'t be bothered with (that\'s what the Boinc platform is supposed to do).
The scheduling and debt experts need to address these concerns, however I can say that while BOINC is still not perfect in wu management (will it ever be?), it\'s improved vastly over the years.
I also suspect that in your case it may need to learn a bit more about your situation over the long term and that means weeks or even a couple of months, not days. These days, micromanagement tends to interfere with, rather than aid boinc\'s learning ability. This may mean that you need to let it miss a few deadlines and make the necessary debt adjustments before it holds back on the work requests. I understand this may seem counter intuitive and may not sit well, however it may be what is required. I suspect that cancelling the wu\'s before they\'ve been crunched prevents boinc from learning that it\'s overcommitted and allowing it to make the necessary adjustments.
I have used a few suspicions here because I use a small cache and concentrate my work mainly on this project, so fortunately (unfortunately?) I don\'t experience these problems.
If they don\'t care about people with larger cache sizes than 1.75 days running into deadlines and consequently deleting WU\'s that pass the deadlines, than things are fine as they are of course.
I find that the admins here do actually care for their contributors. Far more than at other projects, which is why we have such a casual, relaxed and positive relationship with them. I don\'t believe that retaining their existing policies regarding deadlines is a question of not caring. You\'ve read the official reasoning that, as far as I can tell, still holds.
As for deleting wu\'s, the system is designed with redundancy to cater for such situations, so the work that you discard will be recycled without much fuss. TBH, I suspect you will eventually tire of this micromanagement behaviour because it seems like effort best spent on more productive pursuits. :)
/
If it may take month to settle, the complete debt-system would need re-pavement, but I think this isn\'t the case. Though I\'m only crunching for a couple of month, my crunching habits are pretty consistent, so there would be no need for the learning system to get out of control all the time. On my other computer this is also not necessary, but I don\'t run malariacontrol on that one so it can\'t disturb the scheduler. But as far as my understanding of the debt system goes, it doesn\'t need to take that long, and deleting WU\'s to keep it out of priority mode only speeds up the settlement process, but it has to be repeated once in a while, and when attaching new projects, or running projects that do not deliver WU\'s all the time, like LHC.
As it runs out of balance too much every time (sincerely affecting other projects as well), there\'s no other option for me than to micromanage. If I don\'t, Boinc keeps on crunching past-deadline WU\'s (I don\'t understand why it keeps on crunching over-date WU\'s in the first place) and other projects also will pass their deadlines that otherwise wouldn\'t have done that, so I\'ll have to micromanage that anyway not to lose too many flops (and I assume projects don\'t need the over-date WU\'s anymore as well).
Another solution than extended deadlines would maybe be an override-setting in the project preferences to assign cache per-project, so one could have 10 days for all projects, still 1.5 for Malariacontrol, so only malariacontrol would run out of work in case I\'m forced off line for a couple of days.
Hmmm... another two cents. Does this influence my short term debt or long term debt?
I/I
/
Boinc keeps on crunching past-deadline WU\'s (I don\'t understand why it keeps on crunching over-date WU\'s in the first place) and other projects also will pass their deadlines that otherwise wouldn\'t have done that, so I\'ll have to micromanage that anyway not to lose too many flops (and I assume projects don\'t need the over-date WU\'s anymore as well). I/I
In SOME instances, a unit that is returned after its deadline will still get credit. These are pretty specific but they are: the unit is re-issued to someone else because it did not get retuned on time, that second computer does not return that unit before the original computer, that is still crunching the same unit, the original computer will get credit issued to it. If the second computer does return the unit before the original computer, then the original computer will get no credits. When I was a message board admin over at Seti we saw this question many times and they, being the writers of Boinc, were working on setting up the scheduler part so that the overdue units were sent out to subsequent computers that consistently returned units in a very short period of time. That means that if you have not started a unit before it has expired and then return it almost immediately after crunching that unit, you probably will not get credit for that unit.
I do however agree with Chris in that your process of aborting the unit is not letting Boinc figure out that it is getting too much work for your way of crunching and you may be micro-managing for a very long time to come.
Each Project has its own settings for how much work to get and maintain, Your Account, Computing Preferences, Computer is connected to the Internet about every (Leave blank or 0 if always connected. BOINC will try to maintain at least this much work.). If you set this to say 1 day, then you will have 3 days to crunch that one days worth of work and maybe Boinc can figure it out for you, without causing you to crunch for nothing.
____________
/
Mikey, that\'s the way it\'s supposed to happen and it does happen that way most of the time but too often it just doesn\'t happen that way. The reasons why it doesn\'t always happen that way are well known so I\'m not going to rehash that tale here.
What\'s needed is an opt in automatic overdue task abort feature that is hard wired, with double/triple/quadruple checks, to never abort a CPDN task.
____________
--
/
I\'ve been having too many problems all the time with this deadline issue and unfortunately I had to stop crunching this project. If the project can\'t find a solution for this, then I won\'t for sure. I never crunch for the credits (I don\'t understand those who do), but I just get too many problems with other projects running on the same machine that are getting pushed over their deadline. And all of this because I\'ve set a 3-day cache.
The last solution I can come up with is that the estimated crunchtimes would be overrated with a factor 3 or 4 or more, as the max. cache setting is 10 days (I\'ve read on another project that the projects can manage this somehow), but I don\'t know if Boincs \"learning-intelligence\" would correct this over time so I\'d be back where I started again after a while.
I won\'t detach this project and I\'ll be back once in a while to check out if things have gone for the better.
I\'m really sorry, this is one of the most useful projects I\'ve seen on Boinc so far and I hate to let it go, but I see no other solution.
I\'ll keep an eye on the thread, so if someone still has another solution, I\'ll be happy to try, as long as it doesn\'t involve reducing my cache size.
Good luck with the project.
I/I
/
I\'ve been having too many problems all the time with this deadline issue and unfortunately I had to stop crunching this project. If the project can\'t find a solution for this, then I won\'t for sure. I never crunch for the credits (I don\'t understand those who do), but I just get too many problems with other projects running on the same machine that are getting pushed over their deadline. And all of this because I\'ve set a 3-day cache.
The last solution I can come up with is that the estimated crunchtimes would be overrated with a factor 3 or 4 or more, as the max. cache setting is 10 days (I\'ve read on another project that the projects can manage this somehow), but I don\'t know if Boincs \"learning-intelligence\" would correct this over time so I\'d be back where I started again after a while.
I won\'t detach this project and I\'ll be back once in a while to check out if things have gone for the better.
I\'m really sorry, this is one of the most useful projects I\'ve seen on Boinc so far and I hate to let it go, but I see no other solution.
I\'ll keep an eye on the thread, so if someone still has another solution, I\'ll be happy to try, as long as it doesn\'t involve reducing my cache size.
Good luck with the project.
I/I
I think the \'problem\' is that the data here at Malaria is used by the scientists fairly quickly after it is returned by us crunchers. Other Projects, Seti for example, has data that was crunched years ago and is still not being analyzed. That is just one of the reasons I left and will never go back! Anyway with the scientists here inputting our results into their work fairly quickly, longer turnaround times are probably not in the plans. Some projects just do not play nice with each other on some computers schedules. Apparently yours is one of them. If in the future things change, on either side, you will be welcomed back with open arms!!!
____________
/
Mickey, you may hug me as I\'ve embraced Malariacontrol again. I\'ve been shifting around with some of the projects between my computers. My other machine only had pretty long WU\'s from other projects and because of that only one or two Malariacontrol WU\'s are download at a time after I shifted Malariacontrol to that one. I\'ve been testing for about a week and so far I haven\'t run into deadline problems anymore.
The initial problem has not really been solved yet, but so far I am happy that things seem to be solved for me as this is one of the most useful projects on Boinc.
Happy crunching to everybody.
I/I
/
Mickey, you may hug me as I\'ve embraced Malariacontrol again. I\'ve been shifting around with some of the projects between my computers. My other machine only had pretty long WU\'s from other projects and because of that only one or two Malariacontrol WU\'s are download at a time after I shifted Malariacontrol to that one. I\'ve been testing for about a week and so far I haven\'t run into deadline problems anymore.
The initial problem has not really been solved yet, but so far I am happy that things seem to be solved for me as this is one of the most useful projects on Boinc.
Happy crunching to everybody.
I/I
Welcome back! Good to have you back. The more the merrier.
/
Mickey, you may hug me as I\'ve embraced Malariacontrol again. I\'ve been shifting around with some of the projects between my computers. My other machine only had pretty long WU\'s from other projects and because of that only one or two Malariacontrol WU\'s are download at a time after I shifted Malariacontrol to that one. I\'ve been testing for about a week and so far I haven\'t run into deadline problems anymore.
The initial problem has not really been solved yet, but so far I am happy that things seem to be solved for me as this is one of the most useful projects on Boinc.
Happy crunching to everybody.
I/I
A virtual hug is headed your way!
____________
/
Blush :)
Good to be back
/