The thing about reporting many units though is not really thought through properly anyway.
Users that have always on connections, will probably notice that shortly after completing a unit, and before any of the other triggers to report units has happened, the scheduler decides that the computer is short of work and requests more. Along with this request for more work the computer also reports the completed unit.
Occasionally in the msgs I have seen the reporting of two units, when requesting work. Any reporting of more than one unit has usually been caused by comms or server problems.
I can't really confirm that one a fast machine. I've reported up to four WUs at a time when everything was running fine. But I think that was still with the old "short" WUs.
I can't really confirm that one a fast machine. I've reported up to four WUs at a time when everything was running fine. But I think that was still with the old "short" WUs.
I have noticed quite frequently that the amount of work assigned (by the project server) is much larger than requested. This was particularly true with some older BOINC CC (5.4.x comes to my mind) which wrongly calculated amount of work required in order to fill-in the desired cache (if my memory is correct, it didn't consider the resource share). This in turn meant that several WUs were done before cache dropped below the 'full' mark ... This effect was directly proportional to cache size so with 'connect every' set lower than, say, half a day, it can't be seen often.
Might be, I'm still on 5.4.11... thought that was the current stable release. But as those "wrong calculations" never gave me any real trouble (I'm on broadband, this PC is easily fast enough to get the WUs done in time and I only do 2-3 projects per host) I didn't really think about it very much... but now you mention it, I seem to remember a behavior like that.
I think the old scheduler would fetch work = connect to interval for each project. The new one (if I've correctly read everything that JM7 has posted) will fetch work so the total amount of work across all projects = connect to interval.
I think the old scheduler would fetch work = connect to interval for each project. The new one (if I've correctly read everything that JM7 has posted) will fetch work so the total amount of work across all projects = connect to interval.
It does look that way. I used to have mine set to 1 day, and I usually had 2+ days of work for 2 projects. Now I am on 5.8.8 and I had just over 1 day worth of work on any machine (except with CPDN but it ignores that one, so the count is still about 1 day of all the other projects). I made the number a little higher, so that I do not run out of work, in case of project issues.
I made the number a little higher, so that I do not run out of work, in case of project issues.
This is very sound advice. Kathyrn is correct in her recollection and unless people are paying attention, there are going to be quite a few "multiple project" upgraders who start complaining that BOINC is now suddenly, for no apparent reason, starting to leave them short of work in their caches. The more projects you support, the more of a "problem" this is likely to be. The solution, of course, is to make an appropriate increase in your "connect to" setting.
v5.8.8 has changed my v5.4.9 DCF so quickly that "time to completion" increases by 10 or 15 minutes each time a task completes. Even though I increased my queue from 1 to 2 days, the DCF is causing boinc to NOT request new work and therefore my finished results are not getting reported without manual intervention.
v5.8.8 has changed my v5.4.9 DCF so quickly that "time to completion" increases by 10 or 15 minutes each time a task completes. Even though I increased my queue from 1 to 2 days, the DCF is causing boinc to NOT request new work and therefore my finished results are not getting reported without manual intervention.
They will get reported without manual intervention. You just have to wait a bit longer :).
Version 5.8.9 is out for testing now and I've loaded it on one of my boxes. Looks OK so far. Why don't you give it a try?
v5.8.8 has changed my v5.4.9 DCF so quickly that "time to completion" increases by 10 or 15 minutes each time a task completes. Even though I increased my queue from 1 to 2 days, the DCF is causing boinc to NOT request new work and therefore my finished results are not getting reported without manual intervention.
They will get reported without manual intervention. You just have to wait a bit longer :).
Version 5.8.9 is out for testing now and I've loaded it on one of my boxes. Looks OK so far. Why don't you give it a try?
I stayed with 5.4.9 instead of installing 5.4.11 because I don't like being the first to try newly released software. My instincts told me not to install 5.8.8 for awhile, I should have listened to them. Ahh, it's no big deal I just reset the dcf periodically... afterall, prior to 5.8.8 I was babysitting because of libcurl and the periodic termination of the core client on downloads. I'll wait until 5.4.9 is officially released; soon I hope.
The thing about reporting
)
The thing about reporting many units though is not really thought through properly anyway.
Users that have always on connections, will probably notice that shortly after completing a unit, and before any of the other triggers to report units has happened, the scheduler decides that the computer is short of work and requests more. Along with this request for more work the computer also reports the completed unit.
Occasionally in the msgs I have seen the reporting of two units, when requesting work. Any reporting of more than one unit has usually been caused by comms or server problems.
Andy
I can't really confirm that
)
I can't really confirm that one a fast machine. I've reported up to four WUs at a time when everything was running fine. But I think that was still with the old "short" WUs.
RE: I can't really confirm
)
I have noticed quite frequently that the amount of work assigned (by the project server) is much larger than requested. This was particularly true with some older BOINC CC (5.4.x comes to my mind) which wrongly calculated amount of work required in order to fill-in the desired cache (if my memory is correct, it didn't consider the resource share). This in turn meant that several WUs were done before cache dropped below the 'full' mark ... This effect was directly proportional to cache size so with 'connect every' set lower than, say, half a day, it can't be seen often.
Metod ...
Might be, I'm still on
)
Might be, I'm still on 5.4.11... thought that was the current stable release. But as those "wrong calculations" never gave me any real trouble (I'm on broadband, this PC is easily fast enough to get the WUs done in time and I only do 2-3 projects per host) I didn't really think about it very much... but now you mention it, I seem to remember a behavior like that.
I think the old scheduler
)
I think the old scheduler would fetch work = connect to interval for each project. The new one (if I've correctly read everything that JM7 has posted) will fetch work so the total amount of work across all projects = connect to interval.
Kathryn :o)
Einstein@Home Moderator
RE: I think the old
)
It does look that way. I used to have mine set to 1 day, and I usually had 2+ days of work for 2 projects. Now I am on 5.8.8 and I had just over 1 day worth of work on any machine (except with CPDN but it ignores that one, so the count is still about 1 day of all the other projects). I made the number a little higher, so that I do not run out of work, in case of project issues.
RE: I made the number a
)
This is very sound advice. Kathyrn is correct in her recollection and unless people are paying attention, there are going to be quite a few "multiple project" upgraders who start complaining that BOINC is now suddenly, for no apparent reason, starting to leave them short of work in their caches. The more projects you support, the more of a "problem" this is likely to be. The solution, of course, is to make an appropriate increase in your "connect to" setting.
Cheers,
Gary.
v5.8.8 has changed my v5.4.9
)
v5.8.8 has changed my v5.4.9 DCF so quickly that "time to completion" increases by 10 or 15 minutes each time a task completes. Even though I increased my queue from 1 to 2 days, the DCF is causing boinc to NOT request new work and therefore my finished results are not getting reported without manual intervention.
RE: v5.8.8 has changed my
)
They will get reported without manual intervention. You just have to wait a bit longer :).
Version 5.8.9 is out for testing now and I've loaded it on one of my boxes. Looks OK so far. Why don't you give it a try?
Cheers,
Gary.
RE: RE: v5.8.8 has
)
I stayed with 5.4.9 instead of installing 5.4.11 because I don't like being the first to try newly released software. My instincts told me not to install 5.8.8 for awhile, I should have listened to them. Ahh, it's no big deal I just reset the dcf periodically... afterall, prior to 5.8.8 I was babysitting because of libcurl and the periodic termination of the core client on downloads. I'll wait until 5.4.9 is officially released; soon I hope.