@Affinity: I agree - in quick tests I also never found it to help. And exception would be e.g. a Phenom I running partly loaded with C&Q on. The working threads get bounced around and idle cores get clocked down, but don't wake up fast enough if they eventually get work again. In effect you run at a lower average clock (~30% in my tests using Matlab). If I remember correctly it's been solved by AMD in Phenom II by reducing the C&Q granularity.
Quote:
That's the simplistic view that Boinc might have. However, the reality can vary dramatically.
I've got Boinc running "4 threads" on this desktop/test system. There's 306 CPU tasks running, with perhaps on average just 6 active at any instant, but many more on each minute and for the first few minutes of each hour.
Boinc likely gets pushed around a bit for those brief blizzards of tasks.
The OS scheduler must be doing a good job because CPU utilisation stays pegged at 100%.
All of which you say is true. There are many other threads which almost never require CPU time slice. And if the are their priority is likely to be higher than BOINCs, so they just get a time slice and BOINC has to wait for them to finish. The sum of that should be <1% on a regular, modern desktop though.
So.. well, yes, one could screw this scheduling up. But then *nix and Win NT (and following ones) have been doing quite a good job at handling this. So the quick and simple answer is "just do it the way we've been doing it since years (almost decades)".
In my opinion it only gets really challenging once your hardware starts configuration starts to deviate from a totally symmetric setup. I.e. you introduce GPUs, maybe other co-processors, cores on a single die and remotely connected chips, hyperthreading etc. But then some of this has already been taken care of since 2003 and the first Opterons.
@Affinity: I agree - in quick
)
@Affinity: I agree - in quick tests I also never found it to help. And exception would be e.g. a Phenom I running partly loaded with C&Q on. The working threads get bounced around and idle cores get clocked down, but don't wake up fast enough if they eventually get work again. In effect you run at a lower average clock (~30% in my tests using Matlab). If I remember correctly it's been solved by AMD in Phenom II by reducing the C&Q granularity.
All of which you say is true. There are many other threads which almost never require CPU time slice. And if the are their priority is likely to be higher than BOINCs, so they just get a time slice and BOINC has to wait for them to finish. The sum of that should be <1% on a regular, modern desktop though.
So.. well, yes, one could screw this scheduling up. But then *nix and Win NT (and following ones) have been doing quite a good job at handling this. So the quick and simple answer is "just do it the way we've been doing it since years (almost decades)".
In my opinion it only gets really challenging once your hardware starts configuration starts to deviate from a totally symmetric setup. I.e. you introduce GPUs, maybe other co-processors, cores on a single die and remotely connected chips, hyperthreading etc. But then some of this has already been taken care of since 2003 and the first Opterons.
MrS
Scanning for our furry friends since Jan 2002