I just ran the cpu benchmarks with the latest boinc command line client, and it only sees 2 of the 4 CPUs on my PowerMac G5 Quad.

Since the latest PowerMacs all use dual-core CPUs, I wonder: do the other Macs with one dual-core package also see 2 CPUs, or only one?

I just ran the cpu benchmarks with the latest boinc command line client, and it only sees 2 of the 4 CPUs on my PowerMac G5 Quad.

Have you set the preferences on the project website to allow use of all 4 CPUs? The default is 2...

Plus, the benchmark results SHOULD be for _1_ CPU, as each result will only be crunched on 1 CPU. I assume you're instead referring to the "number of CPUs detected" line. I don't use the CLI, so my reference would be the Messages tab. Rest assured, there are several people running Quads, on SETI and Einstein, and BOINC is using all 4 cores. You only have to look at the "Top Computers" list on either project to see this!

---

I just ran the cpu benchmarks with the latest boinc command line client, and it only sees 2 of the 4 CPUs on my PowerMac G5 Quad.

Have you set the preferences on the project website to allow use of all 4 CPUs? The default is 2...

Nice call! I had never even looked at those preferences. I had no idea to look there. Now I'm looking at 0% idle, which is fantastic. (Pardon the pun--I wonder what this will do to core temps and fan activity.)

Thanks!

On further observation, it seems rare that I get all four CPUs running BOINC projects. I'm running seti, predictor & einstein. Most of the time 2 projects are getting about 99%, (usually the same project), and I have about 50% idle time. Sometimes restarting helps for a while. One odd thing is that this computer has cached 11 seti WUs, yet I rarely see it running seti. I did install Team MacNN's optimized seti worker app, and it has completed about 20 results in two days. But it hasn't returned any since 9AM this morning, nor does it seem to be working through the cached backlog.

So, I'm confused. With work already downloaded and ready to start on all three projects, I'd expect BOINC to keep all the CPUs busy. What am I missing?

I did spot a similar question on the seti board, and it was suggested to change the "Connect via network" setting from .1 to .01 hours. I did that and restarted, with no obvious improvement.

Thanks...

Not having run the CLI, I don't know if you can _also_ run the BOINC Manager or not... I for one have no idea what to tell you if I can't ask "what is in the work tab" type questions. Maybe someone else with the CLI can help?

---

I just ran the cpu benchmarks with the latest boinc command line client, and it only sees 2 of the 4 CPUs on my PowerMac G5 Quad.

Since the latest PowerMacs all use dual-core CPUs, I wonder: do the other Macs with one dual-core package also see 2 CPUs, or only one?

I think I answered my own question. The SETI site isn't handling file transfers, and my Quad has finished all the backlog, just not uploaded. The latest Predictor client generated a kernel panic, and I haven't gotten any new WUs for a bit.

So I signed up for Rosetta. 10 minutes later, I had 4 CPUs at full capacity. Life is good!

So I signed up for Rosetta. 10 minutes later, I had 4 CPUs at full capacity. Life is good!

Rosetta is one of my favorite projects, but their Mac app has been having some problems lately. (Naturally, you just signed up, right?!?) Hopefully it will work fine for you, as it does for most-but-not-all, and I'll see you on the Rosetta boards.

---

I take it back--I continue to have problems keeping more than two CPUs busy on my Quad.

When I add a new project, I get all four working until the initial WUs complete, but then it reverts to two scheduled CPUs. I've tried setting the default prefs to 8 CPUs max, I've even added a "home" preference setting, since all my projects think they're at home. I've made sure the changes have propagated to my boinc client by running it manually from the Terminal and watching the output. It's reading the brand new preferences, but I still only get 2 einstein WUs running.

I know there's more work that could be downloaded and running. I have 30 WUs locally, most of which are completed SETI WUs that haven't uploaded their results yet. The only unfinished WUs are the two einstein WUs in progress, and two seti WUs that seem to have failed download, since the files have been zero bytes in size for a few days.

So, I manually deleted them in the various XML files. That seemed to go well, and the scheduler asked predictor and seti for more work. Predictor downloaded and started a new WU, and seti attempted a download that so far hasn't materialized.

IN SUMMARY (sorry for the long-windedness) I think the current boinc core client needs some tweaking to detect when a project isn't able to use its share of resources, and use those idle cycles for another project. Users shouldn't have to manually edit XML files when downloads fail. And if the local WU allocation (which is 30 on my Quad) fills up with completed WUs, make it bigger so more work can continue. In my case, I have 1 to 2 idle CPUs that could be working on rosetta, more einstein, or even predictor projects, but for these two reasons, the scheduler can't make it happen.

Set Seti to get no more work and see what happens....

---

BOINC Wiki

Set Seti to get no more work and see what happens....

Actually, I think you'll have to Suspend SETI. And possibly make your cache just a _bit_ larger, enough to have a couple of extra results "ready to run" - maybe move it from 0.1 to 0.25.

I don't know the CLI version, but editing XML shouldn't be necessary; you can abort transfers if you have the GUI version, there should be some equivalent...

---

Running 2 840ee ht enabled and with the backlog of seti, I was not getting any WUs for other projects so I set Seti to no more work and bingo I started getting WUs....

---

BOINC Wiki

Set Seti to get no more work and see what happens....

Thanks for the idea. I tried it, and boinc is still trying to DL a seti WU. I think it was grandfathered from before the nomorework setting. Uploads continue to fail 100%. And I still have an idle CPU.

Set Seti to get no more work and see what happens....

Thanks for the idea. I tried it, and boinc is still trying to DL a seti WU. I think it was grandfathered from before the nomorework setting. Uploads continue to fail 100%. And I still have an idle CPU.

Vibeeen,

If you "Suspend" Seti from the Projects tab, it will still be able to U/L and D/L whatever is enqueued, but it will let that idle processor know that it won't have a Seti WU to crunch "any second now" and free it up to process something else. That's why it remains idle, it thinks there's imminent work. ;-)

Regards,

Michael

---

"The arc of history is long, but it bends toward Justice"

Set Seti to get no more work and see what happens....

Actually, I think you'll have to Suspend SETI. And possibly make your cache just a _bit_ larger, enough to have a couple of extra results "ready to run" - maybe move it from 0.1 to 0.25.

I don't know the CLI version, but editing XML shouldn't be necessary; you can abort transfers if you have the GUI version, there should be some equivalent...

I tried to suspend the seti project. That function uses the same CLI command that does lots of other things, like nomorework, allowmorework, update, and reset. But suspend generates the following error message:

Unknown op suspend

I tried a few deliberate misspellings, to no avail. So, I think there's a bug here, too. I made sure that seti was set to allowmorework before setting suspend, in case the state machine was sensitive to a transition between two non-operative modes. It didn't seem to make a difference.

I'll make the cache a bit bigger and see what happens.

If you "Suspend" Seti from the Projects tab, it will still be able to U/L and D/L whatever is enqueued, but it will let that idle processor know that it won't have a Seti WU to crunch "any second now" and free it up to process something else. That's why it remains idle, it thinks there's imminent work. ;-)

Regards,

Michael

Thanks, Michael, that answers a concern I had about suspend. Alas, the latest CLI doesn't seem to support suspending a project.

I'm not sure about the imminent work idea. Seti has a 30 resource share, and the other 3 projects all have 3000 resource shares, so I'm surprised that seti has kept that one CPU waiting all day today. I've updated all the projects locally so they reflect their resource allocation.