BOINC 3.20 available - all standard platforms

[chaz]

Yes I understand, I think the work unit cache should revolve around the benchmark and not be able to be changed by the user.

Also I think the server should(if it's possible) monitor incoming and outgoing wu's and be able to differentiate between brand new wu's and wu's currently undergoing the verification process. Work units that have returned and have been reassigned for verification should have a shorter deadline, or higher priority. I think this would help keep the stats more consistent also.

[BC]

Yes I understand, I think the work unit cache should revolve around the benchmark and not be able to be changed by the user.

Also I think the server should(if it's possible) monitor incoming and outgoing wu's and be able to differentiate between brand new wu's and wu's currently undergoing the verification process. Work units that have returned and have been reassigned for verification should have a shorter deadline, or higher priority. I think this would help keep the stats more consistent also.

WU's which are close to their deadlines are indeed pushed out first...
Also you will notice that BOINC runs the jobs in order of due-date.

I have had some WUs come and because of the 'drop-dead' date, had only 48 hours for the turn around..... forunately I only need 48 minutes or so per WU and those WUs got handled right away.


************************************************** **********
I would like to propose that we, as a team, consider setting our BOINC settings to a) ensure Network_Service has full_control of the BOINC/Predictor directory (haha) and b) set our queues to be no more than 2 days long... and c) with (if possible) no more than 1/4 to 1/2 day min/max delta..

Just make sure you have enough WUs extra to handle a short interruption in the database / splitter... (which won't be more than a couple WU's per machine average)

******************************



I've seen the queue min-fill work very very nicely.. that code is solid. I have had 3 WU's go up, and it downloaded 4.... it gets very very stable and predictable after a few empty-fill cycles.


Suggestions / Comments?


BC

[WienerDog]

good idea........ive already got my que set that way,seems to work fine for me [-o<

[BC]

My queue is a bit longer.... and am working on pulling it down with each update...

[BC]

Attention all:

At approx 12:30 AM PST (0730 UTC) SUN 11-JUL-04
The database got hit with a bunch of client errors (cough .. sorry .. cough ... from someone ... cough cough... make sure nobody notices.. LOL ) and stopped responding.

The appropriate log files were sent out to the DBA and given her tendency to check the DB all the time, I suspect it will be up and these error catching triggers (which I think are the cause of the hiccup) will be corrected.

For historical knowledge:

We (but mostly Seti, who was plagued) used to have the problem that client errors would get past the front end and into the core of the database mechanism which, once there, would foul up the entire database.... corrupting and invalidating everything associated with it.

The recent triggers now catch these errors as a user does an 'update' at the front end database where uploads are stored until 'pending' or 'validated'. This is new code to protect the core science AND our credits. It also is supposed to stop someone from sucking up hundreds of WUs and returning 0 time / 0 credit type conditions.

It is my belief that a syntax error (typo) exists and I just caused the DB to flip out since it happened within seconds of my error event. It had been 100% solid until then.

I apologize... whether it be me or not, it could be coincidental and/or contributory... I'm sure the DBA will have things back up early AM (about 5-6 hours from now) when she logs in and get's my email.

If any issues, Please let me know.





On a good note: I have two more machines (a 1P and a 2P) both ready to go as 'services' once the DB is running. They are not the fastest, but since they do nothing but hardware raid servicing, they have CPU time to burn.... approximate mips = 3600, and I think FPU is about 2000. Not fast, just good solid workhorses.

Email or PM me with questions or comments.

Thanks for your patience...
BC.

[nickth]

well db is still down :evil:

[WienerDog]

ya and all my machines are outta work :evil:

[BC]

Hang in there please....

it's already being worked on....


(Yes, I am still awake... and it's 6:36am PST). I will sleep for a few
while the 'boss takes the helm'.

suggestion: when 'user page' comes back up.... set prefs to 2 and 2.1 days. I think that will keep us all busy and within 2 days we will all be within 2 hours sync of each other.

if 1 and 1.1 are more preferable, someone please post.... I will follow the group concensus


When the DB comes back up, we will be all caught up....

Also learned... to force update prefs......

a) stop the service (if using CLI) or exit GUI.
b) edit prefs on web page
c) restart.

works much cleaner for all.


BC

[jlangner]

Yall get off the predictor site. I can't view my stats!! lol.

"Warning: mysql_pconnect(): Too many connections in /home/predictor/packages/boinc-3.19/projects/predictor/html/inc/db.inc on line 15
Unable to connect to database - please try again later Error: 1040Too many connections"

[BC]

Yall get off the predictor site. I can't view my stats!! lol.

"Warning: mysql_pconnect(): Too many connections in /home/predictor/packages/boinc-3.19/projects/predictor/html/inc/db.inc on line 15
Unable to connect to database - please try again later Error: 1040Too many connections"

Jeff, that is the error.. the db is hung... it's being fixed right now.
please be patient... I apologize for the delay.


BC

PS: this 'BC' is going 'offline' for a few hours... when the DB is back, restart your GUI's and CLI's and force the update and all will be fine.... the other servers are sitting there ready to go.

GAWD, I can't wait for the 3.21 (M2) GUI.... SOOOO much easier.