If you pause a single WU in the list, you will likely find a few surprises.

Better -- don't. That will make BOINC to ignore that unit at all. Technically speeking -- it would be out of buffer. Then BOINC might request more.

No, completely wrong. BOINC doesn't work like that at all.

Cheers,

Al.

Jord,

I can do as you asked but what will be the name of the resulting log file?

New values from today

Project LTD
superlink -5040
einstein -20145
hydrogen 0
lhc 47388
milkyway -5563
mindmodeling 3140
qmc -3563
seti -7288
cosmology 0
AIS -8927

LTD reset.

Since projects that are in communications deferral are already removed from these calculations, you are potentially double removing them which could lead to a negative total resource share.

Well, I didn't see that as

 
        if (!p->active.size()) {
	    double rsf = trs ? p->resource_share/trs : 1;
            p->cpu_shortfall = work_buf_total() * overall_cpu_frac() * ncpus * rsf;

so there's a shortfall for a suspended project with no work
and a project with no work but which is not suspended has a shorter shortfall (as total_resource_share contains suspended project too).
and it seems to me that there's a link between shortfall and work_request.

Another point, I'm testing,
when a project with no work is getting work, set the STD to a value linked to the share and the LTD. The purpose is to start quickly a project with a big LTD, in order to avoid the increase of it as STD is smaller than some other projects.
Actual LHC case : Small work and then nothing to do for 4 or 5 days.
So in this case, LTD is bigger after the computation than before (when many projects are running).

boinc manager 6.2.19 - win 2k and win xp operating systems.

for five projects, einstien@home, seti@home, Milkyway@home, malariacontrol.net and climateprediction.net, the completion time rises on average 55 minutes per hour of run time. Also when the the progress = 100%, it runs for another hour or so before reporting. I do not have this problem on 2 other win xp machines, nor on 1 additional win 2k machine.

I am picking on this mail list because the multiple apps suggest that the problem is with the boinc manager. Several virus checkers indicate that there is no problem.

any suggestions?

thanks LouB

Thanks a lot for your prompt reply.

This is the science application which is taking up the CPU, not BOINC.

The applications are 3X+1 and ABC.

According to the Task Manager, priority of these applications are set to low, while other applications (video, play game, etc..) are set to normal.

I have strictly respected the same actions on both win32 and win64, and win64 really take 100% of the CPU.

You can do the following test :
- set boinc manager preferences to "Only after computer has been idle for 3.00 minutes"
- start to look at an avi video for exemple on the same computer
- after 3 minutes, because you have not touch the mouse or the keybord (just look at your video) boinc manager will restart the calculations
- on win 32, when restarting, it takes only the free cpu (on dual or quad core)
- on win64, when restarting, it takes all the cpu and your video is really slowing down

Hoping that my explanations are clear enough. If not, do not hesitate to require me additionnal informations.

New values from today

Project LTD
superlink -10404
einstein -14965
hydrogen 51294
lhc 33060
milkyway -16793
mindmodeling -9831
qmc -8641
seti -41535
cosmology 29699
AIS -11883

Other changes :
I changed the rr_simulation and total_resource_share functions too in order to disable the time used by a suspended project with no active or pending results.
So each active projects are now requesting more works than before.
- changes are not on this computer -
I suppose it may cause overwork when restarting project, but it's not very different than adding project.
I think it's much more like work buffer settings as those projects are not reserving work time anymore.

Ok, so you didn't unsterdand, sorry about it.
As you wrote it

If a project is running long term in EDF, no other project would ge asked for work. ...
Another thing that happens in that situation is that some projects end up with very large negative LTD values and aren't asked for work for a very long time.

So if they don't request for work, they don't have a work request that fail, so the attributes is not set, and everything is as usual.
The conditions to initialize the counter are :
- there's no results for project
- project is suspended by user OR dont request more work is set by user OR there's a work request > 0 that failed.

The counter increases if :
- at least one cpu is not running an edf task

The invisibility becomes if :
- counter reach the limit the user set in "Computing preferences"

As you can see, only the user decide how he manages the share on inactive project (inactive for user - suspending or stopping requests for work, or really inactive for users as he set the deadline beyond which he considers a project with no works is inactive).

But you still have the problem where one task uses extra CPU time - the entire point of long term debt and resource shares is to share the CPU over time. With your modification, you might as well do away with these concepts entirely - leaving absoloutely no method of specifying how the projects should share resources.

I'm sorry, but I don't understand.
- First, you may run boinc as now, if you want to.
- Second, if you run many projects with works, long term is used as now, so if one project is running in edf mode, long term for this project will be negative and the others positive.
- Third, the purpose of this change is to enable the possibility of using share for active projects, not for may be somedays it will be a running project. I think it's easier to manage active projects like this, as you can see in forum, they're some users that cannot manage correctly their share on some projects like Simap, because there's not always jobs to do.
For example, you're running predictor on some computer, what is the long term for this project and for the others ? But may be you detach it ?
I don't have to, because the new management is like a permanent dettach/reattach, I mean you may think that a project with no works for 1 month, 6 months or 1 year, as you wish, is an inactive project, so you may manually dettach this project (and lose the share on this project) - here you don't have to, the long term of this project is reset to 0 and the project become invisible to share management, but continue to seek for new works in case of.
So you don't have to monitor your clients anymore on inactive projects, it's done by the client based on your choice (inactive delay).

Really bad idea. Suppose that CPDN takes over for a year (yes, I have had this happen to some of my computers). Do you REALLY want CPDN to take over for ANOTHER year when it gets the first task downloaded (after a day or less of processing the other project)? What about your resource shares?

Yes, I know, but it works, I mean my attribute is based on work requests, if there's no work requests, then it work as today.
3 cases.
- you have CPDN on your computer (I've got one too), and it is always on edf mode (not mine, you'd better move this project to a faster computer, don't you think ?), so there's no work requests for other projects on this computer, and field is not set, so share is as now.
- you have CPDN on your computer and it run correctly, and an other project with works, so share is as now.
- you have CPDN on your computer and it run correctly, but you've got also another projet like harvard clean energy, hydrogen, ... and don't have any works for now, so the long term is set to 0 on this project until wu's coming.

My share is not based on eternity, but on projects that need my cpu now (running project), if they don't have jobs for me now, that's fine, but I don't want it cause problems on others (very low long term cause other projects to run one by one), and I don't want to detache, reattache in order to reset this attributes.
If I have 10 projects on my computer, my share is 1/10 for each if they give me wus, if one don't give me wu, share become 1/9 for each, and so on.

As I said, you may decide your share, but projects don't care of it, if they don't have any jobs to do, c'est la vie, some projects are closing, where are your share on those after 1 year of very big long term ? Are you sure riesel sieve will continue ? University projects are changing from year to an other, and they need my cpu now, not next year because today I'm running a very large long term project.

I prefer this, but it's a choice, if you want it run as today, just set the parameter to zero (as default), but if you want to set a project with no job for 2 months in pending state, just set this parameter to 61 days.
I think its a good idea, no ?

Add-on : suppose there's 1 million hosts with a fifty-fifty share between seti and simap, as simap don't give works all the time, it means that seti will lose 1 million hosts each time simap give works, that's not the way I see the share.

Hi,
I finally decided to change the boinc core in order to manage share in two ways
- The actual one : share is managed for very long term, as example : 2 projects on one client, same share, one doesn't give any wu for 2 months, and then there's works to do, so it will run alone for 1 month in order to reach the same term as the other, so share is near 66% - 33 % (100 - 0 x 2, 0 - 100 x 1) .
- The new one : share is managed between project with wu, you may select a delay (as parameter) which is the limit until a project with no work become invisible (in resource share), in the previous example, with a delay of 1 week to 2 months, share is near 83% - 17% (100 - 0 x 2, 50 - 50 x 1), share is as usual with a delay upper 2 months.
A new attribute 'out_of_work_time' is added to project ( .xml too), if a project don't have any result (even suspended), and is suspended, or don't need more work, or need work but don't get any, then this attribute is set to 1, each time there's an adjust debt, the wall-cpu-time is added to it. If the attributes is upper the delay, then the project is temporary suspended (long term debt is reset to zero, project is not potentially runnable anymore (except for work request)).
NB :
- wall_cpu_time is stored when suspending tasks, and restored when resuming (I don't think ajusting debt on a project when client was sleeping is fair).
- I kept in mind the message of the highland cow about the edf, so if all the cpus are running edf project, wall_cpu_time is not added to out_of_work_time.

If you're interested in this new management about share, contact me.
- source code based on 6.2.18 -

regards

I have a couple of projects where the long term debt doesn't seem to run down, even though work is available.

The best example is SIMAP where work is generally only available for a week or so each month.

I've given SIMAP a small resource share on the assumption that it will build up a debt over the month

drghughes, sou seem to be attached to (at least) 6 projects. Could you please list them along with their LTD values? (At best once shortly before the 'a week or so' and once just after last SIMAP task was crunched? :-D)

and then run it down when work is available, but this doesn't seem to be the case. Instead, BOINC only seems to request (and schedule) work consistent with the current resource share rather than the long term debt.

Is this the way that things are supposed to work, or does BOINC have a problem with projects like this that only have work sporadically?

I think it behaves just as expected (I agree it is not as supposed by the users ;-)

Maybe this helps (I'm not necessarily right on all points, some of them change over time of BOINC development and some might be skewed in my mind, but you will get the idea):

• if you assigh just a small resource share to a project, it's LTD will be lowered/raised just slowly, accordingly to the share,
  
• if the project server is out of work for say 3 weeks a month, it's LTD on your host will not go down at all during that period - this is possibly your main issue?,
  
• if SIMAP work is available for download, your machine will ask for just a bit of work - not according to the LTD (LTD only tells whether the client is allowed to ask for SIMAP tasks), but according to the resource share, because the resource share also tells, how fast the downloaded task should be processed - SIMAP tasks will be crunched interleaved with other tasks, again according to the resource share.
  
• New SIMAP work will be downloaded if available SIMAP tasks are processed and BOINC cache gets partially emptied. Except that all other projects' LTDs will be that low, that SIMAP tasks would be the only ones in your cache. Just in such case the SIMAP tasks will be crunched full-time and regardless of the resource share, not interleaved with other projects' tasks.
  

Peter

It'll only happen when you update or install for the first time. Afterwards never again.

Thank you for your reply. I'll check out the threads you've mentioned. I beg to differ about the one-time only. I'm almost certain I upgraded a Vista machine from 6.2.14 to 6.2.18 and it required a reboot.

Cheers,
Mark

I tried to compile BOINC for the iPod touch 1.0. Gave up after a while, not because it was hard, but because I was running out of battery and the iPod was getting hotter than I like. (it was compiling on the iPod itself, not cross-compiling from my computer!)

Ladies and gentleman, I successfully cross-compiled the BOINC client to the iPod touch (1.x firmware).

I've yet to test it, though :)

EDIT: ok, not really worth running. Look at these benchmarks!

Learn something new every day. Thanks much, Jord, now I can sleep at night!

if using vista go to users in the control panel and turn off user account control. worked good for me. had no problems with bootup after that.

Disabling the system security is not a solution.

Recently I started thinking whether some organization somehow is checking these projects. When I can be sure, whether somebody didn't create the fictional BOINC project, for example in order to break safety barriers and the like?

You can never be sure; just like you can never be completely sure if any .exe you download is malicious, or if there is porn behind a link. But you can use some common sense, assume good faith, and attach only to widely-known projects.