Your BRP7 (MeerKAT) tasks run on external ATI GPU card which has its own 16 GiB GPU memory. So these do not stress system RAM and they only consume CPU cycles part of the time (0.5 CPU can be seen as set by rule of thumb).
Of course. I wasn't talking about RAM and VRAM. Just by letting 1 core thread free of use (15 being used) the work is done at the same speed as if it was alone.
But GPU usage never goes to 100%, it's 90% max even when BRP7 is alone to work. Don't know if it's a driver issue, a boinc issue, a brp issue or if it works as intended. The same goes for Milkyway GPU wu.
Scrooge McDuck wrote:
You should also try out different number of CPU tasks running in parallel (independent of discussed memory constraints). Your CPU has 8 physical cores, presenting 16 virtual ones to the OS. It depends on the current mix of tasks (O3MD1, FGRP5, BRP4, other BOINC projects) running in parallel if this hyper threading feature (2 virtual instead of 1 physical core) improves analysis throughput (earned credits) or if it adds overhead reducing throughput. You can measure task runtimes (yes they differ also between tasks...anyway) for a different number of tasks running in parallel. Sometimes its better to limit number of tasks in parallel even down to 50% (no hyper threading) to increase task troughput per day.
I'm not running after a score. My goal is to make the best of it. The only condition is that i can do my work properly. Experience have to be smooth and computer must be responsive. But i already can see what you're saying and it's kinda wierd.
Two day ago i told BRP4X64 was between 8 and 13 hours. That was all core, 50% ram. It's wasn't working right, yes load was 100% but temps was 65C and all core was 4550-4600 MHz.
Today with 1 core less, BRP4X64 was stable at 7 hours. Temps was higher at 75C and clocks was 4450-4500.
And that's the weird part. For me, higher clock means less duration, and here it's the exact opposite. I know it as to do with wu going from core to core and with all core being used, there must be some waiting around (lower temp). But obviously it's not efficient.
For today i let my computer on all day long to have some reference data, so i wasn't working all time on it.
Leaving 1 free core is better, maybe 2 or more is even better. I'll see.
After that i'll go back to my old habbit (well not leaving the computer on all day long) and i will search for best configuration while i'm working. It's gone take quite some time but it's worth it.
Scrooge McDuck wrote:
It's good to have such problem discussion here. It's a science project. Problems can only be discovered (or excluded) this way.
Yes it is.
Scrooge McDuck wrote:
I think Einstein isn't very different than other projects. Only memory requirements of O3MD1 CPU tasks are challenging. So it's always a good idea to have a look at the computers process list and memory usage when running CPU task on large proportion of available (virtual) CPU cores. I don't know of other projects, but some FGRP5 and all O3MD1 tasks checkpoint rarely. Developers seem to have good reasons for this. We client users simply have to adapt (or disable such apps in the preferences).
That's it, we users, we just need to understand what the project need and let it aside if we can't adapt. If it wasn't for hibernation i would have left O3MD1 and FGRP5 aside. That's why i aborted all the units in the first place. Why keep them if i can't complete them, better let someone else crunch them in time. Now i have a solution (Hibernation) so i can accept them again.
Scrooge McDuck wrote: Your
)
Of course. I wasn't talking about RAM and VRAM. Just by letting 1 core thread free of use (15 being used) the work is done at the same speed as if it was alone.
But GPU usage never goes to 100%, it's 90% max even when BRP7 is alone to work. Don't know if it's a driver issue, a boinc issue, a brp issue or if it works as intended. The same goes for Milkyway GPU wu.
I'm not running after a score. My goal is to make the best of it. The only condition is that i can do my work properly. Experience have to be smooth and computer must be responsive. But i already can see what you're saying and it's kinda wierd.
Two day ago i told BRP4X64 was between 8 and 13 hours. That was all core, 50% ram. It's wasn't working right, yes load was 100% but temps was 65C and all core was 4550-4600 MHz.
Today with 1 core less, BRP4X64 was stable at 7 hours. Temps was higher at 75C and clocks was 4450-4500.
And that's the weird part. For me, higher clock means less duration, and here it's the exact opposite. I know it as to do with wu going from core to core and with all core being used, there must be some waiting around (lower temp). But obviously it's not efficient.
For today i let my computer on all day long to have some reference data, so i wasn't working all time on it.
Leaving 1 free core is better, maybe 2 or more is even better. I'll see.
After that i'll go back to my old habbit (well not leaving the computer on all day long) and i will search for best configuration while i'm working. It's gone take quite some time but it's worth it.
Yes it is.
That's it, we users, we just need to understand what the project need and let it aside if we can't adapt. If it wasn't for hibernation i would have left O3MD1 and FGRP5 aside. That's why i aborted all the units in the first place. Why keep them if i can't complete them, better let someone else crunch them in time. Now i have a solution (Hibernation) so i can accept them again.