Message boards :
Number crunching :
BOINC 7.0 released to public
Message board moderation
Previous · 1 · 2 · 3 · 4 · 5 . . . 6 · Next
Author | Message |
---|---|
TRuEQ & TuVaLu Send message Joined: 4 Oct 99 Posts: 505 Credit: 69,523,653 RAC: 10 |
Works all okay with the optimized lunatics apps? 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 |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13746 Credit: 208,696,464 RAC: 304 |
Summary of New features ? WTF is a REC-based Scheduler? Grant Darwin NT |
Jord Send message Joined: 9 Jun 99 Posts: 15184 Credit: 4,362,181 RAC: 3 |
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. ;-) |
TRuEQ & TuVaLu Send message Joined: 4 Oct 99 Posts: 505 Credit: 69,523,653 RAC: 10 |
Why the hurry ageless? 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 |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13746 Credit: 208,696,464 RAC: 304 |
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 |
Dave Send message Joined: 29 Mar 02 Posts: 778 Credit: 25,001,396 RAC: 0 |
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? |
Dimly Lit Lightbulb 😀 Send message Joined: 30 Aug 08 Posts: 15399 Credit: 7,423,413 RAC: 1 |
Installed straight over 6.12.34, no problems. I am crunching away :) Member of the People Encouraging Niceness In Society club. |
LadyL Send message Joined: 14 Sep 11 Posts: 1679 Credit: 5,230,097 RAC: 0 |
So Grant, you'll just have to wait a little longer for an explanation of what the REC-based scheduler is. ;-) 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! |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13746 Credit: 208,696,464 RAC: 304 |
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 |
TRuEQ & TuVaLu Send message Joined: 4 Oct 99 Posts: 505 Credit: 69,523,653 RAC: 10 |
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 |
LadyL Send message Joined: 14 Sep 11 Posts: 1679 Credit: 5,230,097 RAC: 0 |
Was that sufficiently clear? 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! |
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
Setting a small 'addtional days' cache will help getting tasks from seti, since BOINC will ask more often, thereby increasing your chances. 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 |
Horacio Send message Joined: 14 Jan 00 Posts: 536 Credit: 75,967,266 RAC: 0 |
Was that sufficiently clear? 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...) |
TRuEQ & TuVaLu Send message Joined: 4 Oct 99 Posts: 505 Credit: 69,523,653 RAC: 10 |
Setting a small 'addtional days' cache will help getting tasks from seti, since BOINC will ask more often, thereby increasing your chances. 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 |
TRuEQ & TuVaLu Send message Joined: 4 Oct 99 Posts: 505 Credit: 69,523,653 RAC: 10 |
Setting a small 'addtional days' cache will help getting tasks from seti, since BOINC will ask more often, thereby increasing your chances. 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 |
Horacio Send message Joined: 14 Jan 00 Posts: 536 Credit: 75,967,266 RAC: 0 |
I'll try set it to 0 and I'll see what will happen. 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)... |
Jord Send message Joined: 9 Jun 99 Posts: 15184 Credit: 4,362,181 RAC: 3 |
So Grant, you'll just have to wait a little longer for an explanation of what the REC-based scheduler is. ;-) 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. |
zombie67 [MM] Send message Joined: 22 Apr 04 Posts: 758 Credit: 27,771,894 RAC: 0 |
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 |
TRuEQ & TuVaLu Send message Joined: 4 Oct 99 Posts: 505 Credit: 69,523,653 RAC: 10 |
I'll try set it to 0 and I'll see what will happen. 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 |
Jord Send message Joined: 9 Jun 99 Posts: 15184 Credit: 4,362,181 RAC: 3 |
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 - 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. |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.