I have two QCN Alpha program's running under Boinc. I am running two other DP app's also. Why would I have two
QCN programs running...
dual core proc.
winxp
boinc 5.10.45
QCN 4.39
Tom
/ 
Reply
Quote
I think that's a problem with the version 5 client, I suggest upgrading to a version 6 client.
/ Reply
Quote
Carl,
I think it is possible for you to set the server parameters to allow only one WU per host at a time.
This shouldn’t impact those with newer BOINC versions but would limit hosts running older clients to a single WU.
/ Reply
Quote
I have that set but people still seem to get 2. I think it's the way version 5 clients handle the "non-cpu-intensive" directive.
/ Reply
Quote
I have that set but people still seem to get 2. I think it's the way version 5 clients handle the "non-cpu-intensive" directive.
I just installed 2 units - and have noticed the same thing.
I am not sure how to correct this on the server side, but I know that it can be done. 1 Wu per host -
It might just be an issue during the initialization phase of the project I.e. Freehal has a similar problem. When the program is first initialized on BOINC, it will download a bunch of work, but then it will settle in and only ask/allow 1 second of work at a time.
Milkyway as set their cache to 8 WU per core, and other projects have set it up for a max of # per host.
I do have a couple boxes running BOINC ver 6 but are in locations that would not work very will with this project i.e. Next to a weight room where they are always bouncing heavy weights on the floor, and they can be felt through the ground.
I hesitate to upgrade to version 6 - last time I did I lost all my cached work and BOINC settings.. UPgrading form 5x to 6x is not perfected.
/ Reply
Quote
hmmm, there did seem to be a problem with this, somewhere along the line I had set the max_to_send as 5, I've put it to 1 so if you reset you'll now get one workunit (or abort the one extra one you have now)
/ Reply
Quote
I aborted the two QCN's and restarted Boinc - no joy still came up with 2 copies running. Will look at ver 6 for boinc. Tom
/ Reply
Quote
I upgraded Boinc to ver 6.4.5 and that seems to have correct the problem... Tom
/ Reply
Quote
It seemed to be working yesterday.
Now I am getting the message that my BOINC client is too old and needs to be upgraded ..
1/25/2009 11:02:35 AM|QCN Alpha Test|Message from server: CPU app exists for QCN Alpha but no CPU work requested
1/25/2009 11:02:35 AM|QCN Alpha Test|Message from server: (your BOINC client is old - please install current version)
Did you change this ?
If so, I will either have to upgrade or not run this project. - Upgrading to version 6 wipes out all the projects attached, as well as all the work cached WU's. And I have yet been able to figure out how to manage my other hosts BOINC client with the remote option in version 6.
/ Reply
Quote
When you upgrade unless you are going to use CUDA to crunch with your GPU go with version 6.2.19 as I have found 6.4.5 to be a little “buggy” in regard to its work scheduler. Managing remote hosts in version 6 works the same as it did in version 5.
/ Reply
Quote
you don't have to upgrade, that's just a "nag" message from the new boinc scheduler I installed. it will probably be worth upgrading when version 6.8 comes out (probably still a month or two away I would guess). this version will support running QCN at a slightly higher priority so that the sensor data stream is more reliable (esp when running with other BOINC projects).
you can probably set "No New Work" on your client so that when jobs fnish, you can safely upgrade to version 6 (I didn't know an upgrade would lose all workunits & current work).
/ Reply
Quote
you don't have to upgrade, that's just a "nag" message from the new boinc scheduler I installed. it will probably be worth upgrading when version 6.8 comes out (probably still a month or two away I would guess). this version will support running QCN at a slightly higher priority so that the sensor data stream is more reliable (esp when running with other BOINC projects).
you can probably set "No New Work" on your client so that when jobs fnish, you can safely upgrade to version 6 (I didn't know an upgrade would lose all workunits & current work).
Well upgrading from BOINC 5 to BOINC 6 is not "suppose" to loose everything, but it did, and does. Including all the attached projects. It also assigns a new host CPID - which really sucks! - Because then I have to re-attach to everything all over again. Somebody at Berkeley needs to fix the upgrade problems - then I might go through the trouble. It is not a problem for most participants, but those of us with 50 or 60 or more hosts.. it can be an all day job. One that I am not willing to take on right now :)
However, whatever you did in the last hour seemed to work. My 5.10.30 box reported and downloaded a single WU- just like it was suppose to.
Would manually setting the priority on these WU's help? with only a couple boxes running, I could try to remember to do this every couple of days.. maybe :)
/ Reply
Quote
When you upgrade unless you are going to use CUDA to crunch with your GPU go with version 6.2.19 as I have found 6.4.5 to be a little “buggy” in regard to its work scheduler. Managing remote hosts in version 6 works the same as it did in version 5.
I have installed 6.4.5 for a CUDA - but managing hosts does not work.
I have copied over my remote_hosts.cfg and gui_rpc_auth.cfg just as I did with my 5x boxes. but nadda. Still can not "back door" into the host, and am forced to use VNC - a REAL PITA.
/ Reply
Quote
I have installed 6.4.5 for a CUDA - but managing hosts does not work.
I have copied over my remote_hosts.cfg and gui_rpc_auth.cfg just as I did with my 5x boxes. but nadda. Still can not "back door" into the host, and am forced to use VNC - a REAL PITA.
Make sure you have them in the “new” location for BOINC config files for version 6…
C:\Documents and Settings\All Users\Application Data\BOINC
and NOT where the executables are located C:\Program Files\BOINC.
Should work, I use it all the time at home.
/ Reply
Quote