Works all okay with the optimized lunatics apps?

I have no problems with them and BOINC 7.0.25

I do have problems with the scheduling and I have mailed DA about it.
As you recomended me to do with log files and all.
I haven't seen that a fix to the issues has been implemented in 7.0.25.
Why the hurry ageless?

//TRuEQ

---

TRuEQ & TuVaLu

Summary of New features
...
...
...
REC-Based scheduler

?
WTF is a REC-based Scheduler?

---

Grant
Darwin NT

Why the hurry ageless?

Your buglet was not seen as a show stopper. It only happens in a certain combination of hardware and projects, not to all. After your report we only had 1 other person report the same sort of thing, on another projects combo and with other hardware. Which means that for everyone else it isn't a problem.

Now, although I managed to get the release of this client postponed by a couple of days so we could (re)write the documentation, the problem here is that I am (re)writing much of the documentation, Eric Myers is adding to it and shuffling pictures around and perhaps the developers are looking in and changing typos. So it's completely the wrong way around in which the documentation is being written, from the least knowledgeable to the best knowing.

Same goes for that thing about the REC scheduler; underneath that mention is a very brief explanation on how it works. But then again, I don't think I can do it any better, as when I want to 'translate' the scheduler write-up to layman's English, I get stuck. if any of you think you can do it, go on then, be our guest.

If you do not have an account on the User Wiki yet, ask David for one. After a spam bot added 2,000 accounts for itself over a 3 day period, we closed account creation again. It's also on my to do list to clean the rest of them up.

But that's after the write up of a page on the virtual machines, on OpenCL, on that new scheduler, and a couple of other pages that need to be redone to BOINC 7.0 standards. It feels like work, yet I don't get paid for it. Why do I do it then? Because otherwise no one would do it, and then we'd still be in all those forums pointing everything out to everyone asking about it in their own threads. Which gets very boring after a while.

So Grant, you'll just have to wait a little longer for an explanation of what the REC-based scheduler is. ;-)

---

Why the hurry ageless?

Your buglet was not seen as a show stopper. It only happens in a certain combination of hardware and projects, not to all. After your report we only had 1 other person report the same sort of thing, on another projects combo and with other hardware. Which means that for everyone else it isn't a problem.

Well, it is great that it has come to a fresh release.
I know you guys been buzy implementing the OpenCl-support.
And also alot of work with something I didn't understand that was T4T@Home realated.

Great work on theese accievements.(However it is spelled). ;)

I also "feel" that the new work-fetch scheduling routine is something else.
it is very good in tuning what project should be run next.

It is only me and my special rig that has a problem with running 5 GPU projects at once and as my "faulty" config of project SETI with an ATI ap app .r560 that has problems getting work since they are "rare" tasks to get nowadays.
The problem is that the BM does not ask for tasks in long periods of time.
The project resource is set to the highest of the projects.
There is 0 tasks in cue and yet the BM refuses to ask for new tasks.
The other projects that has tasks in cue runs as smoothly as I think they are ment to and they schedule as they should and keeps filling their cues to a "normal" level.
But with 1 project not giving out enough tasks to keep the cue "normal" something happends and the BM stops or nearly stops requesting work.
Which will lead to that specific project will always remain with the lowest debt and this will continue in a catch22 loop forever as I see it.

I hope I am clear enough explaining what I've encountered here.
Otherwise, please ask and I'll try to be clearer.

Keep it up!!!

//TRuEQ

I appologize for any miss spellings here, I know I do them....

---

TRuEQ & TuVaLu

So Grant, you'll just have to wait a little longer for an explanation of what the REC-based scheduler is. ;-)

No worries.

---

Grant
Darwin NT

So I spend about 4 weeks revving beta 7 down so I can go back to 6 to get a decent cache & 3 days later v7 comes out LOL!

Not for me yet. See what I can do RAC-wise with 6. Will there not be any trouble getting GPU work now 7's out properly?

Installed straight over 6.12.34, no problems. I am crunching away :)

---

Member of the People Encouraging Niceness In Society club.

So Grant, you'll just have to wait a little longer for an explanation of what the REC-based scheduler is. ;-)

No worries.

REC = recent estimated credit

This is only relevant if you run more than one project.

What the client does is, it keeps a record of how much CPU/GPU time a certain project has recently seen. This translates into the REC. It compares this figure with the project share that has been set. A project that has worked less than its share will get priority in both scheduling (running tasks) and work fetch. Then as it gets crunchung time its REC increases and another project will get to the head of the queue.
Over time you get a more or less good distribution of crunching time according to resource share.

Points to note:
GPUs are very productive so lead to high REC. If you run GPU projects along CPU ones on similar shares the GPU project sees virtually no CPU.
CPU and GPU are scheduled separately.
SETI will probably stay pretty high up in the queue, since getting tasks is hit and miss
Setting a small 'addtional days' cache will help getting tasks from seti, since BOINC will ask more often, thereby increasing your chances.

Was that sufficiently clear?

---

I'm not the Pope. I don't speak Ex Cathedra!

Was that sufficiently clear?

I think so, maybe.
The resource sharing between projects instead of being based on the time spent processing for each, will be based on the credit earned for each? Is that it?


Is this so that projects that over pay for work get less processing time (on hosts that do multiple projects of course), or some other reason?



BTW- thanks for the explanation.

---

Grant
Darwin NT

Setting a small 'addtional days' cache will help getting tasks from seti, since BOINC will ask more often, thereby increasing your chances.

What number shall it be set to to get the highest number of requests per hour?

Is 0 to prefere if you want it to ask more freqvently?

//TRuEQ

---

TRuEQ & TuVaLu

Was that sufficiently clear?

I think so, maybe.
The resource sharing between projects instead of being based on the time spent processing for each, will be based on the credit earned for each? Is that it?


Is this so that projects that over pay for work get less processing time (on hosts that do multiple projects of course), or some other reason?



BTW- thanks for the explanation.

You're welcome.

No, actual credit granted by the projects is not used, it's just an internal number based on crunching time. (therefore 'estimated' credit).
It assumes equal 'pay'.
The new logic works far better in making sure projects get time slices according to their resource share.
In BOINC 6 projects could be deemed 'overworked' and still continue fetching and running tasks. In 7 if a project is overworked its workfetch and scheduling priority will be very low - it will still get some additional work, if all the other projects ahead in the queue don't get (enough) work.

---

I'm not the Pope. I don't speak Ex Cathedra!

Setting a small 'addtional days' cache will help getting tasks from seti, since BOINC will ask more often, thereby increasing your chances.

What number shall it be set to to get the highest number of requests per hour?

Is 0 to prefere if you want it to ask more freqvently?

//TRuEQ

If you need it to ask very frequently, 0 additional would be correct. The 303 second request_delay in sched_reply will of course still limit the number of requests per hour to 11 or 12.

                                                                   Joe

Was that sufficiently clear?

I think so, maybe.
The resource sharing between projects instead of being based on the time spent processing for each, will be based on the credit earned for each? Is that it?


Is this so that projects that over pay for work get less processing time (on hosts that do multiple projects of course), or some other reason?



BTW- thanks for the explanation.

You're welcome.

No, actual credit granted by the projects is not used, it's just an internal number based on crunching time. (therefore 'estimated' credit).
It assumes equal 'pay'.
The new logic works far better in making sure projects get time slices according to their resource share.
In BOINC 6 projects could be deemed 'overworked' and still continue fetching and running tasks. In 7 if a project is overworked its workfetch and scheduling priority will be very low - it will still get some additional work, if all the other projects ahead in the queue don't get (enough) work.

Sounds good, but Im not sure that will help when faced with SETI issues...
Im crunching for SETI and Einstein and even while the debts for Einstein are allways hughe negative numbers, the differences beetwen both projects make it very hard to the scheduler to honor the share load...
I mean the scheduler (6.10) really tries to get work for SETI but, ussually it fails (or get just a couple of WUs) and then it has to wait 5 mins to try again, so it ask Einstein, who is almost allways ready to send a lot of work and its delay is only 1 minute... when the scheduler is able to ask again for SETI work the cache is now full...

Will this new BOINC version refrain to request work for Einstein while is waiting to be able to ask for SETI work again?
I know the best way to test this is installing the new version, but as it is not compatible with previous ones, im reluctant to try because it will be hard to undo... (and I know that the backoff is not as bad as 6.12, but they are still there...)

---

Setting a small 'addtional days' cache will help getting tasks from seti, since BOINC will ask more often, thereby increasing your chances.

What number shall it be set to to get the highest number of requests per hour?

Is 0 to prefere if you want it to ask more freqvently?

//TRuEQ

If you need it to ask very frequently, 0 additional would be correct. The 303 second request_delay in sched_reply will of course still limit the number of requests per hour to 11 or 12.

                                                                   Joe

I'll try set it to 0 and I'll see what will happen.
I've had it set to 4 earliar-
And every time I've decreased it, it has started to say "not reporting or requesting tasks".

As of earliar I only got my cache filled with low resource project tasks.
And Seti stopped asking leaving the SETI(highest resource) with an empty cache and no new requests.

I'll leave it set to 0 and monitor the progress.

//TRuEQ

---

TRuEQ & TuVaLu

Setting a small 'addtional days' cache will help getting tasks from seti, since BOINC will ask more often, thereby increasing your chances.

What number shall it be set to to get the highest number of requests per hour?

Is 0 to prefere if you want it to ask more freqvently?

//TRuEQ

If you need it to ask very frequently, 0 additional would be correct. The 303 second request_delay in sched_reply will of course still limit the number of requests per hour to 11 or 12.

                                                                   Joe

I'll try set it to 0 and I'll see what will happen.
I've had it set to 4 earliar-
And every time I've decreased it, it has started to say "not reporting or requesting tasks".

As of earliar I only got my cache filled with low resource project tasks.
And Seti stopped asking leaving the SETI(highest resource) with an empty cache and no new requests.

I'll leave it set to 0 and monitor the progress.

//TRuEQ

It didn't really work that well.
It kept asking for SETI ap tasks and the BM got none since the server had 0 task ready to send.

And while waiting for the communication deferred 5mins it filled the cache with Milkyway, Primegrid, SETIBeta and POEM.

So after the 5mins it said "not requesting new tasks" when I hit the update button.

But, I somehow have circumvent the SETI ap work fetch to be more frequent now.
I have a 3day cache with 0 additional now.

And I let the other projects reach about 1.5 day of cache(then setting them to NNT) leaving only SETI to request new tasks. And it does with an interval of aprox 7mins.
Which let me have 1 task an hour or maybe 2 tasks an hour from the server.
I am doing about 1-2 tasks every hour so my cache won't be filled with a 3 days of work.
And that makes SETI keep requesting new tasks for me.

YES!!! Finally I found a way to trick the BM to fetch the work for me so I won't have to click the "update" button all the time.

*heh*

//TRuEQ

---

TRuEQ & TuVaLu

I'll try set it to 0 and I'll see what will happen.
I've had it set to 4 earliar-
And every time I've decreased it, it has started to say "not reporting or requesting tasks".

As of earliar I only got my cache filled with low resource project tasks.
And Seti stopped asking leaving the SETI(highest resource) with an empty cache and no new requests.

I'll leave it set to 0 and monitor the progress.

//TRuEQ

It didn't really work that well.
It kept asking for SETI ap tasks and the BM got none since the server had 0 task ready to send.

And while waiting for the communication deferred 5mins it filled the cache with Milkyway, Primegrid, SETIBeta and POEM.

So after the 5mins it said "not requesting new tasks" when I hit the update button.

But, I somehow have circumvent the SETI ap work fetch to be more frequent now.
I have a 3day cache with 0 additional now.

And I let the other projects reach about 1.5 day of cache(then setting them to NNT) leaving only SETI to request new tasks. And it does with an interval of aprox 7mins.
Which let me have 1 task an hour or maybe 2 tasks an hour from the server.
I am doing about 1-2 tasks every hour so my cache won't be filled with a 3 days of work.
And that makes SETI keep requesting new tasks for me.

YES!!! Finally I found a way to trick the BM to fetch the work for me so I won't have to click the "update" button all the time.

*heh*

//TRuEQ

Yep, what I've thought... IF BM keep asking other projects after just one request to SETI, SET is doomed... LOL

Babysitting Boinc works, but meanwhile who is not working is me... :O

I think that the only solution is to have a per project threshold, so if the queue for a certain project is above a certain value (user choice?/ porportion of the cache affected by the share ratio of the project?) then it will not ask work for that project unless it is the one at top of debts, if the one at top cant supply enough work then it will only ask work for the projects that are under their cache share and only to fill up to their cache quota (which will avoid filling the whole cache)...

---

So Grant, you'll just have to wait a little longer for an explanation of what the REC-based scheduler is. ;-)

No worries.

You'll have to wait quite a bit longer, as the developers do not want any technical explanations in the User Wiki. They feel that should go in Trac Wiki. This after we moved everything about the client to the User Wiki a year or so ago... sigh.

Anyway, we're having a discussion about that through email. Until that time I stopped writing the OpenCL, virtual machines and REC-based scheduler (with quote by LadyL) pages, as I'd rather not have to (re)write it twice.

---

This constant push to hide how BOINC works, is frustrating and insulting. We're just too dumb to handle the technical stuff. And I think it ends up doing just the opposite of what (I think) their goal is. IMO, of course.

---

Dublin, California
Team: SETI.USA

I'll try set it to 0 and I'll see what will happen.
I've had it set to 4 earliar-
And every time I've decreased it, it has started to say "not reporting or requesting tasks".

As of earliar I only got my cache filled with low resource project tasks.
And Seti stopped asking leaving the SETI(highest resource) with an empty cache and no new requests.

I'll leave it set to 0 and monitor the progress.

//TRuEQ

It didn't really work that well.
It kept asking for SETI ap tasks and the BM got none since the server had 0 task ready to send.

And while waiting for the communication deferred 5mins it filled the cache with Milkyway, Primegrid, SETIBeta and POEM.

So after the 5mins it said "not requesting new tasks" when I hit the update button.

But, I somehow have circumvent the SETI ap work fetch to be more frequent now.
I have a 3day cache with 0 additional now.

And I let the other projects reach about 1.5 day of cache(then setting them to NNT) leaving only SETI to request new tasks. And it does with an interval of aprox 7mins.
Which let me have 1 task an hour or maybe 2 tasks an hour from the server.
I am doing about 1-2 tasks every hour so my cache won't be filled with a 3 days of work.
And that makes SETI keep requesting new tasks for me.

YES!!! Finally I found a way to trick the BM to fetch the work for me so I won't have to click the "update" button all the time.

*heh*

//TRuEQ

Yep, what I've thought... IF BM keep asking other projects after just one request to SETI, SET is doomed... LOL

Babysitting Boinc works, but meanwhile who is not working is me... :O

I think that the only solution is to have a per project threshold, so if the queue for a certain project is above a certain value (user choice?/ porportion of the cache affected by the share ratio of the project?) then it will not ask work for that project unless it is the one at top of debts, if the one at top cant supply enough work then it will only ask work for the projects that are under their cache share and only to fill up to their cache quota (which will avoid filling the whole cache)...

Yes, a proportion of the cache based on the resource set would do the trick.

Then a project with resource set to 200 and another project set to 100 will have a aprox 67% and 33% of the cache as it's maximum. And would ask for more tasks as soon as that project is below that.


//TRuEQ

//TRuEQ

---

TRuEQ & TuVaLu

This constant push to hide how BOINC works, is frustrating and insulting. We're just too dumb to handle the technical stuff. And I think it ends up doing just the opposite of what (I think) their goal is. IMO, of course.

I can see David's point in the last exchange:

A common complaint about BOINC - and reason why people don't run it -
is that it's "too complicated".

We're computer people, and so are the people we talk to every day.
We tend to forget that the average computer owner - the kind we need to attract if we're going to go from 300K users to 10M - is not. He/she views their PC as an appliance.

When we put more information on the user Wiki, we create the impression that users need to understand that info in order to run BOINC. This drives off the non-computer people.

So "General information" and "Running BOINC: basic" needs to be as simple as possible.

"Running BOINC: advanced" can have more advanced content, but it needs to be about how to actually use BOINC, not about how BOINC works internally.

But on the other hand, I feel the information should go somewhere and not in the Trac Wiki, which is more geared towards setting up a project, running the server software, and all the very technical conclusions on how things work. Too complicated for the person who wants to learn more about BOINC without needing to have a crash-course in C/C++ programming.

So we probably need a third place, if only to temporarily store all this information, until they see the light in Berkeley.

---