I'm noticing a problem with the way BOINC (v5.10.20) schedules tasks to run in the background on Vista Business (32-bit) with Pentium-4 HT enabled CPUs.

The client will start up one project per CPU core to run in the background with idle priority. So far so good.

But when I run x264, a multicore aware video encoding application, BOINC is not respecting something and never lets go of one of the cores and forces that other core to share time with x264. This of course gives lackluster encoding performance but can only be remedied by stopping the BOINC service.

Can anyone verify this?

What project(s) are you running?

---

I'm noticing a problem with the way BOINC (v5.10.20) schedules tasks to run in the background on Vista Business (32-bit) with Pentium-4 HT enabled CPUs.

The client will start up one project per CPU core to run in the background with idle priority. So far so good.

But when I run x264, a multicore aware video encoding application, BOINC is not respecting something and never lets go of one of the cores and forces that other core to share time with x264. This of course gives lackluster encoding performance but can only be remedied by stopping the BOINC service.

Can anyone verify this?

HT means not Dual-Core. You have only a SingleCore-CPU with 2 virtual Cores. First real Dualcores for X86 was P4-D or A64-X2.

What project(s) are you running?

CPDN, Rosetta, LHC, and Einstein.

I've watched them all exhibit this behavior, that's why I thought it might be BOINC instead of something project-specific.

HT means not Dual-Core. You have only a SingleCore-CPU with 2 virtual Cores. First real Dualcores for X86 was P4-D or A64-X2.

This is true. Windows doesn't know the difference. And since I'm not dealing with the Pentium-D or X2 (or higher) CPUs, I'm back to pointing out I'm seeing this on a HyperThreading Enabled CPU. Until I get to work on Monday I can't verify if I can reproduce this on a P4-D or Core2 CPU and isn't part of my original post anyway. :)

But when I run x264, a multicore aware video encoding application, BOINC is not respecting something and never lets go of one of the cores and forces that other core to share time with x264. This of course gives lackluster encoding performance but can only be remedied by stopping the BOINC service.

If you're not setting CPU affinity manually and you're using official BOINC Core Client (which doesn't have CPU affinity setting functionality), then it's really not up to BOINC CC to move science applications from one (logical) CPU to another if needs arise. That's up to OS CPU scheduler - some OSes have more decent ones than the others.

---

Metod ...

What project(s) are you running?

CPDN, Rosetta, LHC, and Einstein.

I've watched them all exhibit this behavior, that's why I thought it might be BOINC instead of something project-specific.

HT means not Dual-Core. You have only a SingleCore-CPU with 2 virtual Cores. First real Dualcores for X86 was P4-D or A64-X2.

This is true. Windows doesn't know the difference. And since I'm not dealing with the Pentium-D or X2 (or higher) CPUs, I'm back to pointing out I'm seeing this on a HyperThreading Enabled CPU. Until I get to work on Monday I can't verify if I can reproduce this on a P4-D or Core2 CPU and isn't part of my original post anyway. :)

To solve your problem and slowdowns in all your projects try to set up in General preferences "On multiprocessor-systems, Use at most >1< processor" or change that entry in global_prefs_override.xml.

---

To solve your problem and slowdowns in all your projects try to set up in General preferences "On multiprocessor-systems, Use at most >1< processor" or change that entry in global_prefs_override.xml.

But either way, aren't BOINC projects supposed to run on idle CPU time and should always throttle back no matter how many cores are running BOINC apps?

I understand the role the OS plays when it comes to scheduling tasks, but it still doesn't make sense to limit BOINC's scheduling to 1 CPU in regard to multiple virtual/physical cores when running multicore applications.

I still need to check out this behavior on a P4-D.

But either way, aren't BOINC projects supposed to run on idle CPU time and should always throttle back no matter how many cores are running BOINC apps?

Nope. BOINC projects run on low priority, and it's up to the OS to "throttle them back". That's it.

---

To solve your problem and slowdowns in all your projects try to set up in General preferences "On multiprocessor-systems, Use at most >1< processor" or change that entry in global_prefs_override.xml.

But either way, aren't BOINC projects supposed to run on idle CPU time and should always throttle back no matter how many cores are running BOINC apps?

I understand the role the OS plays when it comes to scheduling tasks, but it still doesn't make sense to limit BOINC's scheduling to 1 CPU in regard to multiple virtual/physical cores when running multicore applications.

I still need to check out this behavior on a P4-D.

What priority are the encoding task(s) running... any chance the are also set to "low"...

Sorry about the PM, hit the wrong button.

at first glance this might seem unimportant due to HT "fake" dual cores being a thing of the past.
But nehalem is set to bring HT back, with 4 real cores + HT for 8 virtual, and 8 real cores + HT for 16 virtual.

This would make this issue quite problematic, and it places us in an interesting position where a bug can be identified and fixed with a future technology before it even arises.

Is there any way to determine HT existance automatically and then automatically divide the number of "cores" by 2 for that machine?

---

I do not have a superman complex; for I am God, not Superman!

You could (manually) set the use-max-num-of-CPUs. Note that this doesn't vary according to idle/busy.

It is really the operating system's job to deal with low-priority jobs appropriately since a user-level app shouldn't need to be responsible for knowing what type of multiprocessing is happening.

---