Einstein ignoring prefs
15 Nov 2016 15:47:29 UTC
Topic 202794
(moderation:
Presently running Seti (share 98%), and Einstein (share 01%). Checked my prefs, just using 'generic', all seem golden. Lately (I don't agonize over direct computing so lately might mean two months) been getting sixty work units at a time for Einstein. Ran for the longest time at 60/40 Seti/Einstein but noticed Einstein was by far the largest amount of wu's by a factor of four or so when compared to Seti. This is taking in effect CPU/GPU units for both projects. Adjusted the shares to 70/30, then 80/20, and finally 98/01. No change in the amount of Einstein vs Seti wu's. Same result using local prefs or web prefs. Have Einstein prefs set for one day of work. Put Einstein on no new work. Might be something stupid that I've overlooked...don't have any teenagers here to help figure it out (G)...TIA!
Firstly and it's not much
)
Firstly and it's not much comfort, it's not Einsteins fault it's Boinc and how it works. You do as you did, set your prefs to what you want and then Boinc uses that to request work from your different projects, the projects then assigns work based on your request. A project can never force work upon you, it's always Boinc that requests it. How that works (or is supposed to work) is described in this wiki and this design document.
How to get it to do what you want is the real challenge and it might not be fully possible.
First one needs to accept that it's a long term thing, a change might take weeks to fully take effect. Setting resource share to wildly differing numbers might lead to unexpected results.
Secondly one should never expect the number of workunits to match the set resource share, at times there might only be work from project A in cache and at other times it might only be from project B. Setting Einstein to a low resource share should, given time, lead to fewer tasks in cache.
You might be able to speed up the process of finding a new equilibrium by using a cc_config.xml (documentation here) with the <rec_half_life_days> option set to a day or two.
Thanks. I didn't look into
)
Thanks. I didn't look into the BOINC side of things. Will do that now. It's just that everything runs well for so long and then something doesn't just makes me wonder. I'm thinking I did a BOINC update and that messed things up. I'll pop over to the SETI site and see what I can find..thanks again!
peristalsis wrote:Thanks. I
)
Holmis has pretty much explained the problem but there are a couple of other things that may be making things worse. Many people who want to use Seti as the major project often set a large work cache setting. This is to be able to keep running during outages or periods of no work availability. This is fine except that if Seti doesn't supply for any length of time, BOINC will request work to fill the cache from any of your other projects that can. This is probably why you end up with a lot of Einstein work. BOINC will then choose to run the Einstein work in preference to Seti when it gets close to deadline. BOINC puts more importance in honouring deadlines rather than resource shares. It always tries to fix resource share 'later'. By the time it has fixed the deadline problem and is ready to go back to Seti, there might be a Seti outage so even more Einstein gets downloaded. None of this would happen if Seti could always supply work.
If you keep quite a small cache setting, BOINC wont accumulate a whole bunch of either Seti or Einstein tasks and you will quickly run out of Seti work when Seti is 'dry'. However, as soon as Seti has work again, BOINC will be able pretty much be able to do Seti exclusively whilst trying to 'catch up' to the proper resource shares. In the long run, you actually may end up doing more Seti work that way, provided Seti doesn't have too many long outages. I don't follow Seti at all so I don't have any experience on which to judge. You will need to decide about that for yourself.
I don't think updating BOINC would have caused your problems. What version did you update from?
Cheers,
Gary.
Running seti at 5 days.
)
Running seti at 5 days. Couldn't find anything on Einstein but I didn't look too hard. The 'old' BOINC install should not have been too old, generally see a new one, wait a couple of weeks, then upgrade if thee is no uproar. What has me curious is the change from 'running dine' to 'this doesn't seem right'. Think I'll just stop worrying about it and get on with my life. Thanks all for he help...p
peristalsis wrote:Running
)
BOINC will use the preferences from whichever project where you last changed them. You should always try to choose a 'main' project and only change them there. They will then propagate to your other projects. So, unless you override website preferences with local preferences, whatever you set at Seti will also apply at Einstein - ie. 5 days.
There's no problem with 5 days if all projects can regularly supply work. If Seti stops supplying, say for a day or two, BOINC will request all that work from Einstein. This may not be too bad if both projects have roughly equal resource shares. If the resource share for the project that always can supply (Einstein) is very low, BOINC will soon realise there will be looming deadlines for the excess Einstein work and will soon have to go into 'panic' mode in an attempt to deal with the excess. It perhaps wouldn't have needed to do this if Einstein had a bigger resource share. It may have been able to handle the excess as part of normal crunching. Just do the estimate for yourself. If the resource share is 50%, a 1 day excess of Einstein tasks could be handled normally in 2 days. For a resource share of 5%, a 1 day excess would need 20 days of normal crunch time. It's little wonder that BOINC will quickly go into panic mode and ignore resource share in this situation.
I was just wondering if you had upgraded from a very old version of BOINC. Seeing as you hadn't, a small step in BOINC version shouldn't be an issue.
If you want a 'set and forget' experience without large numbers of excess Einstein tasks, set your resource shares between 50/50 and say 70/30 in favour of Seti and set your work cache size to something like 0.5 days. That way, you will limit the number of tasks that BOINC sources from Einstein when Seti can't supply. When Seti has work, crunching of Seti should be able to resume quite quickly since you will only have a small excess of Einstein work that wont be causing BOINC to invoke 'panic' mode any time soon.
Cheers,
Gary.