I searched for this topic with no luck so I'll ask.

I've been running Seti for a few years and recently
added Einstein but am confused about resource share.
I set both for 100 which gives each 50%, but of what?
They appear to be switching at the default interval of
60 minutes, so what is being shared? I remember years
ago on a Modcomp II mini-computer, it gave each task
a 50ms time slice so all tasks appeared to run simultaneously. BOINC seems to be "all or nothing"
for each project for 60 minutes.

My OS is Win2k with AMD 2400+ CPU, 512 RAM, 80G drive.

Any clarification woill be appreciated

Mike

Mike Sr.,

What you describe is exactly what it should be doing, given your preference settings. The resource share is time share, but both projects do not run simultaneously on a single non-hyperthreaded processor, they run alternately.

Regards,

Michael

---

"The arc of history is long, but it bends toward Justice"

Mike,

The Wiki is your friend ... you can look up questions like this there ...

But, simply put, the resource is your computer's time.

WIth a 50/50 split your computer will give each project 50% of the available computing power. Note that this is OVER TIME... you will see one project or another running, but, over time, the average will be 50/50 ...

For more complex "looks" I give shares from as high as 90 (at times) to as low as 1 ...

My current "spread" is 1% to 50% with most computers having a 1% to 25% ...

But, I run a minimum of two, and usually more like 8 or 9 projects on each computer.

WIth more projects, SEVERAL can go off line and I will not even notice it ... when I use up the work for one project, I will start to run work more for the other projects. When the off-line project comes back, I will re-allocate effort to the project.

---

Mike,

The Wiki is your friend ... you can look up questions like this there ...

But, simply put, the resource is your computer's time.

WIth a 50/50 split your computer will give each project 50% of the available computing power. Note that this is OVER TIME... you will see one project or another running, but, over time, the average will be 50/50 ...

For more complex "looks" I give shares from as high as 90 (at times) to as low as 1 ...

My current "spread" is 1% to 50% with most computers having a 1% to 25% ...

But, I run a minimum of two, and usually more like 8 or 9 projects on each computer.

WIth more projects, SEVERAL can go off line and I will not even notice it ... when I use up the work for one project, I will start to run work more for the other projects. When the off-line project comes back, I will re-allocate effort to the project.

So, If I change the ratio of the resource shares, will the 60-minute interval
for switching between projects change? This is where I have problems
understanding the concept. If BOINC switches from one project to the next at
fixed intervals, as long as there is work to be done, then each will get the
same amount of computer time, regardless of the resource share proportions?
On the other hand, if the 60-minute interval is proportioned between two
projects based on a resource ratio of 50-50, then a switch would occur every
30 minutes.

I guess it boils down to the question, Is it the switching interval that is
rationed out or something else?

Thanks for taking the time to indulge a dunce.

Regards,
Mike

The resource shares and the switching time are both under your control, and are independent of each other. Most leave the switch at 60 minutes.

If you set SETI to 50 and Einstein to 100 and Rosetta to 200, then it will run SETI for an hour, Einstein for an hour, Rosetta for two hours, Einstein for an hour, Rosetta for two hours, back to SETI... (1:2:4) or some seemingly random pattern somewhat like that.

The "guarantee" on resource share actually isn't even "per day" - it's "in the long run". If you have a result, say from Einstein, that somehow (you shut down the computer for a week, whatever) is in danger of missing the deadline, BOINC will run Einstein _only_, nothing else, until it's able to make the deadline. But it keeps track of that, so it may then run _no_ Einstein for a week, letting the other projects catch up.

Look up "long term debt" and "short term debt" in the Wiki for all the details. STD controls "what runs next", and LTD controls "what work to download".

---

OK, I think I got it. Switching interval determines the minimum time slice,
while resource share determines how many slices to give each project. The
sequence of the allocated slices may depend on the LTD and STD but over a long
period each project will have gotten its proportional share of the total time.

Is that fairly close?

Mike

The resource shares and the switching time are both under your control, and are independent of each other. Most leave the switch at 60 minutes.

If you set SETI to 50 and Einstein to 100 and Rosetta to 200, then it will run SETI for an hour, Einstein for an hour, Rosetta for two hours, Einstein for an hour, Rosetta for two hours, back to SETI... (1:2:4) or some seemingly random pattern somewhat like that.

The "guarantee" on resource share actually isn't even "per day" - it's "in the long run". If you have a result, say from Einstein, that somehow (you shut down the computer for a week, whatever) is in danger of missing the deadline, BOINC will run Einstein _only_, nothing else, until it's able to make the deadline. But it keeps track of that, so it may then run _no_ Einstein for a week, letting the other projects catch up.

Look up "long term debt" and "short term debt" in the Wiki for all the details. STD controls "what runs next", and LTD controls "what work to download".

The one other thing about resource sharing that hasn't been touched on, but you need to be aware of if trying to optimise behaviour, is checkpointing - again, look in the Wiki for the definition. What that means is that each project has its own save points (or not at all). You can defer them in some cases, but that is the only control you have. Close the application program, and on restart it will run from the last save point, not necessarily where you got to last time. Once you've realised that, it is obvious that not only should you leave the application in memory when preempted by another project if you possibly can, but frequent switching is best avoided, especially if you shut down your machine regularly. Although the default may be 60 or 100 minutes, there is no reason why it cannot be much longer.

There seem to be a few people who signed up to several projects, set the switching time to very short intervals, and had 'leave in memory' set to no. Then wondered why they never seemed to complete work units.

---

OK, I think I got it. Switching interval determines the minimum time slice,
while resource share determines how many slices to give each project. The
sequence of the allocated slices may depend on the LTD and STD but over a long
period each project will have gotten its proportional share of the total time.

Is that fairly close?

Yep! I wouldn't call it a "minimum" time slice, as there are a number of other things that can cause a reschedule, such as you hitting "update", a result finishing... things that can cause BOINC to switch "earlier" than an hour. But left alone with results that take over an hour to run, you're right on. It's actually a _maximum_ time that BOINC will allow something to run without coming back and taking a look at it. It may well decide to give it another hour, but it at least has rechecked.

One caveat to the "will get it's share" rules; beside you messing with things (changing prefs, suspending projects, attaching new ones), the debts also are affected if the project _has_ no work to send. For example, LHC releases work only in "bursts" of activity. If LTD was allowed to build continuously for LHC, then when it did send work, nothing else would get done. LTD does build _some_, but not constantly in that kind of situation. Your SETI debt probably has _not_ gone up drastically today, if you were one of the unlucky ones to get no work; projects don't get bonuses for not consistently giving you work, they get penalized.

The scheduler isn't perfect, I know of two "minor issues" that need to be fixed, and a needed enhancement - but it IS pretty darn smart...

---

OK, I think I got it. Switching interval determines the minimum time slice,
while resource share determines how many slices to give each project. The
sequence of the allocated slices may depend on the LTD and STD but over a long
period each project will have gotten its proportional share of the total time.

Is that fairly close?

Aside from small details, Paul votes yes ... :)

For me the key idea is that it sets the proportions of work effort done... I can look at a project and determine how interested I am in the goals of the project, how well they treat the participants, how stable are the applications, etc.

As an example, SETI@Home has been pilloried about the troubles during the change over. *I* think that it went about as well as we have any right to expect. All-in-All, we got there in just about a week. Not bad for a major change. So, as I reward, I have given the project slightly more resources recently.

Predictor@Home is not acknowledging some errors with their application nor talking much to the participants, they are not interested in us, well, I am not that interested in them ...

Rosetta@Home has had a couple problems with the application (one instance cost me 25 hours of compute time ...) but, they have been looking and talking to us about it ... just the last couple days there have also been work issued that dies early, but, again, they let us know they are looking into it, and I think they have fixed the second problem, a new application is supposed to help with the first, but they are not sure they have that yet.

So, my shares wax an wane, but, I concentrate on projects that are doing science. Just my personal interest. So, I only talk to this to give you some ideas of what to do ... I think most people, even on slower systems should have a mix of 3 projects to provide against outages.

---

Thanks everyone for the in-depth clarification. I'm only using a single machine
at a relatively slow 2GHz but it runs nearly 24/7, so I wanted to optimize the
efficiency. A few of the preference settings, like the resource share, are
somewhat counter-intuitive since the default of 100 implies a percentage but
apparently it's not. Same for the Write to Disk parameter which could be
taken as a checkpointing interval but is not. From what I've read, checkpointing
is a function of individual projects and not BOINC.

I think I now understand enough to get the most out of my setup without going
any further into the nuts and bolts, which was my intention in the first place.

Happy Holidays to All,
Mike

Same for the Write to Disk parameter which could be taken as a checkpointing interval but is not. From what I've read, checkpointing is a function of individual projects and not BOINC.

Well... sort of... it sets a "don't checkpoint until at least this much time has passed" value. If the project's application tries to checkpoint every second, for some strange reason, this setting should cause it to only checkpoint every "x" seconds instead. If the project app only checkpoints every 10 minutes, then the fact that you have the "every x seconds" set to 60 seconds is irrelevant.

You knew it couldn't be _that_ easy! :-)

---

It is a checkpoint no more often than setting ...

Yes, the resource share is not a percentage but a ratio/proportion ... However, I set mine to integer numbers that all add up to 100, and check my math ... :)

I find it easier to work with that way. THough the project shares don't quite come out as percentages ... I am waiting to see if the project management sites will make this work or not. Probably not ... :)

---