I've just noticed that Milkyway N-Body application (multithread) is using all my boinc time.
When a WU is downloaded the estimated time is over 100 hours and Boinc runs milkyway in high priority with all cores, blocking other projects.
Anyone is having the same behaviour?

I've just noticed that Milkyway N-Body application (multithread) is using all my boinc time.
When a WU is downloaded the estimated time is over 100 hours and Boinc runs milkyway in high priority with all cores, blocking other projects.
Anyone is having the same behaviour?

Multi-threaded applications are designed to use all of your cores to do the work. The 100 hours is just an estimate and it should come in well under that.

---

Yes, in fact it takes 10 minutes to complete the WU... but with an estimated time over 100 hours Boinc runs Milkyway N-Body in high priority as soon as a WU is downloaded.
So, when a WU is completed and reported a new WU is immediately downloaded and starts in high priority, blocking other project with shorter deadlines and cause other project WUs to complete out of time.

At the moment I was "luck" and it downloaded a Milkyway 0.88 app that with an estimated time of 3,5 hours give the possibility to other projects to work...

Yes, in fact it takes 10 minutes to complete the WU... but with an estimated time over 100 hours Boinc runs Milkyway N-Body in high priority as soon as a WU is downloaded.

Have you tried resetting the MW project to reset the BOINC Duration Correction Factor?

Have you tried resetting the MW project to reset the BOINC Duration Correction Factor?

Yes, I tried, but with no success.

My correction factor was around 1.00, but with these WUs is decreasing (now it's 0.9).

Odd. None of my "mt" WU's have higher than 1h20m expected run time. And even that was on a machine with DCF of 19.8 for MW.

Yes! I used to have this problem too! :-)

It takes eternity to come down with those estimated times over 100 hours closer to the 10 minutes. I think it tends to happen more on CPUs with great single-core-TurboBoost difference from the normal freq. when running all cores at 100 percent. For example take my i7 720QM 1.6 , it runs at 1.73 when 8 cores are active, but it TurboBoosts up to 2.8 when just one thread is running. The estimation calculation must be really REALLY confused by this and the error multiplied by 8 cores... and here You go: 100 hours instead of 0.25 hour. Still strangely significant difference though. :-)))

---

Melwen - Child of the Fangorn Forest
Rig "BRISINGR" [ASUS G73-JH, i7 720QM 1.73, 4x2GB DDR3 1333 CL7, ATi HD5870M 1GB GDDR5],bought on 2011-02-24

I see this behavior too...
MW is supposed to only use 50% of the available processors.
Why is it not honoring the preferences ???
JR

I see this behavior too...
MW is supposed to only use 50% of the available processors.
Why is it not honoring the preferences ???
JR

As Arkain said: "Multi-threaded applications are designed to use all of your cores to do the work."

And N-Body is a multi-threaded application.

now, it only takes BOINC manager a few minutes to adjust estimated times for NBody Sim. - with those small testing units (12 seconds each, on a dual core P4 2.2GHz).
That was a good idea: to send newly re-connected computers about ten or more WUs of extremely short duration to learn BOINC client the estimated time calculation.
Good job, MilkyWay at HOME admins ! :)

I got those super-short WUs too, but that didn't help me. The 0.88-WUs (single thread) get estimated times around 120 hours - and take about 4 hours to complete. The N-Bodies (4 Thread) work fine for me; estimates are immediately correct. The estimated times just scale down while the WU is beeing worked on; so after, say, 2 hours the WU is at 50% and estimated time is at 60h remaining. Of course these WUs get high priority, cause if the time was correct they mightn't make the deadline. Haven't tried resetting yet, though. But Milky is the only project that's doing this...