Hi Colin,

If you look at the Number Crunching MB you will see that myself and greg_be have had calculation problems with some of these.

Let me know if these are just the odd glitch or if we have a systemic problem.

Thanks
John

i have one of these now, All other runs on this machine take 2.x hours max to run. This one has a forecasted run time of 42 hours

Hi Robert,

I am not sure if your problem is the same as mine as my WUs dont take that long.

If you look at the Number Crunching MB in a thread started by greg_be then you will see the details of the error sequence.

John

I haven't received any new downloads for this project in days now? Any idea the problem, is it something I'm doing wrong?
____________
____________
YukonMan.com

Your deadlines are 11 days out, apps with deadlines 4 days out aren't getting a single CPU cycle. If your 4 apps continues to hog all 4 CPUs on this machine, you'll find the MIPS I donate no longer available to you. Simple guys. Back it off and quickly. You have 16 elapsed hours from the time of this post.

Your new Nbody_110K_Plum_xxxxxxxx burns through my system in 1:33 (1 minute 33 seconds)
What kind of data are you running that disappears that quick?

Also why is it using all 4 cores of my cpu and running in high priority? Its not due until may 3 for crying out loud.

Once again I am disabling Nbody because it is just buggy when it comes to run on my CPU only system.

If your 4 apps continues to hog all 4 CPUs on this machine, you'll find the MIPS I donate no longer available to you. Simple guys. Back it off and quickly. You have 16 elapsed hours from the time of this post.

If your 4 apps continues to hog all 4 CPUs on this machine, you'll find the MIPS I donate no longer available to you. Simple guys. Back it off and quickly. You have 16 elapsed hours from the time of this post.

First of all, CALM DOWN!

I think this is caused by a bug that was introduced with the new dont_use_dcf command in Boinc 7.0.24. It makes the client assume that all tasks are about to miss the deadline, thus run them in high priority mode. This should affect all tasks of all projects that set dont_use_dcf.

By the way, if I understand correctly how dont_use_dcf works, one should try to avoid using an app_info.xml on such projects, bug or not.

For those of us not experienced in editing or removing sections of the Boinc Mgr program, how do you change whatever is causing this problem.

On the other hand 3 other projects do not have this problem and the PS tasks also do not have this problem. So why do the Nbody tasks have this issue?

Why not modify what ever the offending code is in the task rather than have us novices go monkying about in the programs behind boinc mgr?

Interesting that PS tasks go bad on your GPU while Nbody tasks go crazy on my CPU.
PS works great for me.

But I am curious how Nbody tasks that are out there now burn through the data so quick. I thought they were to run slower, since I thought they had a lot of data to go through.

For those of us not experienced in editing or removing sections of the Boinc Mgr program, how do you change whatever is causing this problem.

You can't. The problem is in your local Boinc installation and you'll have to recompile the code or find someone to do it for you. This is the patch I used:

diff -Naur boinc_core_release_7_0_25/client/cpu_sched.cpp boinc_core_release_7_0_25_patched/client/cpu_sched.cpp
--- boinc_core_release_7_0_25/client/cpu_sched.cpp 2012-04-14 10:02:12.000000000 +0200
+++ boinc_core_release_7_0_25_patched/client/cpu_sched.cpp 2012-04-22 02:14:30.000000000 +0200
@@ -470,7 +470,7 @@

// treat projects with DCF>90 as if they had deadline misses
//
- if (!p->dont_use_dcf && p->duration_correction_factor < 90.0) {
+ if (p->dont_use_dcf || p->duration_correction_factor < 90.0) {
if (p->rsc_pwf[rsc_type].deadlines_missed_copy <= 0) {
continue;
}

This is part of the code where Boinc looks for tasks to run in high priority. Basically it means, if a project uses DCF (Duration Correction Factor) and the value is somewhat reasonable, consider to leave the task alone. Otherwise it's a candidate for special treatment. Unfortunately, if a project does not use DCF, the "leave it alone" part is never reached.

On the other hand 3 other projects do not have this problem and the PS tasks also do not have this problem. So why do the Nbody tasks have this issue?

If a project uses DCF, which I think most still do, you won't notice anything of this. Look in your client_state.xml file, if you find a line reading "<dont_use_dcf/>" the project that it belongs to should be affected. The whole project. And I say "should" because Milkyway is the only one for me, too, so I can't verify this. But the PS tasks do have the problem, that's why I looked into this in the first place. I noticed both of my GPUs running nothing but Milkyway for half a day.

Why not modify what ever the offending code is in the task rather than have us novices go monkying about in the programs behind boinc mgr?

The offending code is not in the task, nor is it with the project. It is at your end and you can't change it yourself. The project could probably work around it, but you would have to do that for every single project seperately. It's more efficient to fix the problem where it is.

I'll look over at the Boinc site for a contact address, if I find one I'll suggest to change this in the next release. But if somebody knows whom to inform, please feel free to point them here.

reverted back to older version of boinc to solve the problem

reverted back to older version of boinc to solve the problem

reverted back to older version of boinc to solve the problem

oh, really??? I must TRY this solution!

I hate it when GPU tasks are *PAUSED* while CPU-ONLY app "N-Body" is running in high-priority !
This is DEFINITELY a bug. Yes, BOINC Manager bug, probably.
I will downgrade the BOINC immediatelly , NOW! :)

Thanx for this solution, greg_be !

As I wrote, the bug was introduced with a change in 7.0.24, so previous releases are safe from it. Of course older 7.0 versions can't be recommended, so a possible solution would be to switch back to BOINC 6 as you did. Now we all know that you can't simply downgrade from v7 to v6 (we have read the release notes, haven't we?) so here's instructions how to do it.

Meanwhile the fix has been added to the source code so it will be in the next BOINC release, whenever that may me. If you can wait for that, that's another possible solution.

As I wrote, the bug was introduced with a change in 7.0.24, so previous releases are safe from it. Of course older 7.0 versions can't be recommended, so a possible solution would be to switch back to BOINC 6 as you did. Now we all know that you can't simply downgrade from v7 to v6 (we have read the release notes, haven't we?) so here's instructions how to do it.

Meanwhile the fix has been added to the source code so it will be in the next BOINC release, whenever that may me. If you can wait for that, that's another possible solution.

Hello, Colin Rice. All is running fine here.

Running nbody_100K_Plum_EMD and suddenly: there is limit of only one task for my computer (2.2 GHz P4 HT, model E2200 with 2 logical cores).
Yesterday there was 6 tasks. Did You change something? :)

I need at least two, so the second will start immediatelly - not having to wait for the server to be contacted and respond, accept the completed task and finally send me a new one + waiting a few seconds for download of the new one. So, my computer cannot use 100 percent of free CPU cycles... some of them are wasted. Why it has to be limit 1 now? :(

P.S.
Finally, after several hundreds of units, estimated time seems to establish itself near the truth, now around 16 minutes while the real runtime is around 6 minutes. Thats good. :)

suddenly: there is limit of only one task for my computer