High priority wu's?

Message boards : Windows : High priority wu's?

Author Message
Profile Bugg
Send message
Joined: Jun 21 06
Posts: 19
Credit: 23,014
RAC: 0

I just noticed my BOINC stopped working on 4 wu's and started on 4 others and said they were high priority. One problem, the due date/time for the 4 it switched to, were all 4 LATER than the due date/time for the 4 it stopped processing. Is this a Malaria problem or a BOINC problem? Is this the correct forum for this?

Profile mikey
Avatar
Send message
Joined: Mar 23 07
Posts: 4382
Credit: 5,361,193
RAC: 1,084

I just noticed my BOINC stopped working on 4 wu's and started on 4 others and said they were high priority. One problem, the due date/time for the 4 it switched to, were all 4 LATER than the due date/time for the 4 it stopped processing. Is this a Malaria problem or a BOINC problem? Is this the correct forum for this?


It is a Boinc thing and there is no FIX for it, Boinc thinks it knows what it is doing and will do it unless you micromanage it yourself. You DO seem to have a large cache though, @155 units right now. But as long as your pc keeps getting thru them okay I wouldn't worry too much about it. To totally stop the High Priority crunching you need to lower your cache size though. I would lower it by one day and see if that is enough, it will take a few days to work things out so go slowly!!

Profile Bugg
Send message
Joined: Jun 21 06
Posts: 19
Credit: 23,014
RAC: 0

I have my cache set to 0.25 days. I don't have a clue why it would have that many. I'll double check and post if I find something's not set how I remember it.

Thanks!

Profile Bugg
Send message
Joined: Jun 21 06
Posts: 19
Credit: 23,014
RAC: 0

Well, things seem to be set correctly on my end, everywhere I'm looking. So I'll have to micromanage for a bit to clear out these 161 WU's it seems to have given me. I told it to not get new work units, and suspended a TON just to make sure I finish the ones due on 03 Feb, and then will do the same for those due on 04 Feb, then will let it crunch on it's own all the ones due after that, til they're gone.

What a pain!

Profile mikey
Avatar
Send message
Joined: Mar 23 07
Posts: 4382
Credit: 5,361,193
RAC: 1,084

Well, things seem to be set correctly on my end, everywhere I'm looking. So I'll have to micromanage for a bit to clear out these 161 WU's it seems to have given me. I told it to not get new work units, and suspended a TON just to make sure I finish the ones due on 03 Feb, and then will do the same for those due on 04 Feb, then will let it crunch on it's own all the ones due after that, til they're gone.

What a pain!


Yes it absolutely can be! What probably happened is that you finish a unit in like 20 minutes and Boinc, in its infinite wisdom, decided ALL the units will be done that fast and gave you A TON of work, and now that you are back to the normal time frame for crunching the units you have waaay too much work. Boinc can be funky sometimes!

Profile Bugg
Send message
Joined: Jun 21 06
Posts: 19
Credit: 23,014
RAC: 0

After a little digging around on boinc message boards, too, I think what you described is probably exactly what happened. I had my cache only set to 1 day. So that makes sense that it might have been that problem.

On the flip side, I wound up aborting most all of those units, as I had some that were taking 2-4 hours each suddenly, and let it finish those. Then I exited boinc, reset the DCR to 1.000000 (found somewhere on the web that said how to do it step by step) and saved it. I also changed my cache to 0.25 days. Things seem to be running much better now.

Personally, I think this whole problem stems from the fact there's 2 different types of WU's for this project. They also both use a different program (obviously) to analyze said WU's. While most all of the Branch A units seem to be quite short, the major difference in computation times between Branch B units varies greatly. Ok, so I take it back, it seems it's mostly the time for Branch B units. :)
____________

Profile Bugg
Send message
Joined: Jun 21 06
Posts: 19
Credit: 23,014
RAC: 0

I don't know exactly how it works, but this DCF value, seeing as we're doing both Branch A and Branch B units, wouldn't that DCF play into Time Remaining for types (assuming you get both types (which I'm sure we all do anyway)) of units? If so, then this is a problem that should be considered by the devs here at this particular project. No?

Again, just voicing thoughts here. If I can learn more about how that works, perhaps I can keep a cache of a size that will give me no problems (as in aborting a bunch of wu's).

____________

Profile Bugg
Send message
Joined: Jun 21 06
Posts: 19
Credit: 23,014
RAC: 0

Well, less than 100 work units back into the project for me, and already my DCF is up over 13.xxxxxx.

In comparison: I've run over 300 work units from another project that also uses different applications for different types of work units, and my DCF there is only 0.9376. This tells me it's more the project than the boinc client itself. The boinc client is just doing what it's supposed to, and is obviously working properly considering it's not doing this with other projects.

There has to be some way to get this fixed. Perhaps the calculation by the devs or programmers for the application that analyzes the data we get, needs to be adjusted, or something else needs to be adjusted. Either way, just this little "test" kinda shows it's not the boinc client that is the issue.

I really hope something can be done about this, though. :)
____________

Profile mikey
Avatar
Send message
Joined: Mar 23 07
Posts: 4382
Credit: 5,361,193
RAC: 1,084

Well, less than 100 work units back into the project for me, and already my DCF is up over 13.xxxxxx.

In comparison: I've run over 300 work units from another project that also uses different applications for different types of work units, and my DCF there is only 0.9376. This tells me it's more the project than the boinc client itself. The boinc client is just doing what it's supposed to, and is obviously working properly considering it's not doing this with other projects.

There has to be some way to get this fixed. Perhaps the calculation by the devs or programmers for the application that analyzes the data we get, needs to be adjusted, or something else needs to be adjusted. Either way, just this little "test" kinda shows it's not the boinc client that is the issue.

I really hope something can be done about this, though. :)


You can always go into your settings and say don't send this or that type of unit, that would prevent your problems. It is on the webpage under Your Account, about half way down you will see malariacontrol preferences. Then at the bottom of that page you will see:
Run malariacontrol simulation application Yes
Run openMalaria test application Yes
Run map predictor application Yes
Run optimizer application Yes
Run openMalaria A application Yes
Run openMalaria B application Yes

The above are my settings, yours could be different. Edit it to your liking and then make sure you save the settings and then do a manual update of the project so they get pushed out to the pc. That way you shouldn't get any more units of the wrong kinds. You may have to change the settings if you fins that one or the other kind doesn't have enough work for you, the Server Status page does not say how many of each kind, just the total number available.

Post to thread

Message boards : Windows : High priority wu's?


Return to malariacontrol.net main page


Copyright © 2013 africa@home