Here is the problem ran into. I first noticed it on GRCPOOL then went to BAM and discovered the same problem.

What works: At either GRCPOOL or BAM, you set up an account then attach boinc to that account, you then get projects, either the default ones from BAM, or you add them from GRCPOOL (no default there). The resource is 100% on GRCPOOL and "-1" on BAM which gives 100% also. All is fine until you reattach. Either you accidently removed the project manager (easily to do in Boincstats if you are not watching what you are doing), or you do it on purpose to get out of or into pool mining.

The bug: If you reattach, you pick up %100 for resource instead of the last assigned resource values. Forcing a project synch from BM or Bointasks does not change the value from 100 to whatever it last was.

for example: I have Milkyway set to 100% and Einstein set to 0% on a system that has advanced double precision arithmetic hardware (S9000 & 7950 ATI Tahiti GPUs) When Milkyway goes offline (usually every Tuesday for maintenance) my system switches to Einstein. This happens only because of the resource values of 100 & 0 respectively. It is more productive to do Milkyway than Einstein on double precision efficient systems.

I recently reattached to BAM and got %100 for all projects (GRCPOOL ditto). To fix this I discovered that I had to change the value of “0” to a positive integer such as “1”. If I then issue a sync command the value on my system finally changes from 100 to 1. I can then go to BAM and change the “1” back to “0” and issue a synch to finally get the desired “0” on my system.

I suspect the problem is that neither BAM nor GRCPOOL will send the value of the resource if it has not changed AT THE WEB SITE. Thus I must force a change AT THE WEB SITE to get my local system account to be updated with the value I need. Alternately, "0" must have some special significance and is not reported after a synchronization command from BM.

This gets worse for unsuspecting users especially newcomers on GRCPOOL where there is no help or advise available. Not only do you get %100 resource, but you "CAN" also get CPU, ATI, NVIDIA and INTEL tasks even if you have those checked as “do not use”. If you have unchecked ATTACH on BAM or checked DETACH on GRCPOOL then those projects are still attached to your system and issuing a SYNC command does not detach them as the web site does not sense a change. I wrote "CAN" because the projects are smart enough not to send NVIDIA to an ATI only system and vice versa.

What can go wrong in the hour to two (or never for newbies at GRCPOOL) it takes to fix the problem: you can download boat loads of unwanted tasks such as N-Body that take all of your CPU threads (Milkyway and GpuGrid) or double precision tasks for single precision only GPUs (milkyway).

The forum at Milkyway is full of complaints about GRCPOOL users causing so many failed tasks that they are looking at a reliability test to prevent systems constantly reporting failed work units. I suspect users, especially GRCPOOL users, are unaware of the problem they are causing.

I think this is going to be a difficult one to resolve. I think we probably need to get someone to set up an Account Manager account (BAM! is probably better for this purpose than Gridcoin, because Willy has spent more time working with the BOINC developers to ensure that his BAM! works according to the specification).

Make the account, record exactly how it's set up, request attach/synchronise from a BOINC client, capture and preserve the file the AM sends in reply with the settings, and see whether the Client gets settings that match what was set up in the AM.

Then, do it all again under this re-attach / sync situation. Verify the AM account, attach, request sync, capture and preserve the new settings file, and see whether the client ends up with the wrong settings. Then, we can compare what happened at the various stages: did the AM send a faulty file, did the BOINC client mis-read the file, did something else interfere along the way? Then we can work out which part of the complex chain of events is responsible for any error.

It's actually quite important to get to the bottom of this, because a new AM is being prepared for use: we need to be sure that the client is handling things properly so that we can test the new AM thoroughly.