Too Many WUs!
Message boards : Number crunching : Too Many WUs!
| Author | Message | |
|---|---|---|
|
Wow, I attached and began crunching with no problems. I noticed I was getting some lag while surfing the net a few minutes later, and checked the message window to see if one of my currently problematic projects was causing it. It turned out I was still downloading WU's from Docking@home, 300 in all before I managed to get it to stop. I don't know if it's because the expected completion was ~5min (which it's looking like they will probably take more like a few hours), and the DCF hasn't had a chance to stabilize yet since I am just working on my first one, but 300 still seems excessive. I hope I can make the deadlines for them all! Anyone else have this happen?
|
||
ID:
15 | Rating: 0
| rate:
/
|
||
|
I just got 20 on one of my machines and 4 on another. 300 it is a lot you better leave your machine running 24x7 |
||
|
ID:
16 | Rating: 0
| rate:
/
|
||
|
Wow, I attached and began crunching with no problems. I noticed I was getting some lag while surfing the net a few minutes later, and checked the message window to see if one of my currently problematic projects was causing it. It turned out I was still downloading WU's from Docking@home, 300 in all before I managed to get it to stop. I don't know if it's because the expected completion was ~5min (which it's looking like they will probably take more like a few hours), and the DCF hasn't had a chance to stabilize yet since I am just working on my first one, but 300 still seems excessive. I hope I can make the deadlines for them all! Anyone else have this happen? Yes, I just got 50 WUs on one PC and over 300 WUs on another one. Seems to be much to much to crunch in time. Maybe you could change the "maximum daily WU quota per CPU" from 500 to 50 or 100 for the moment? |
||
|
ID:
17 | Rating: 0
| rate:
/
|
||
|
Good idea, setting the quota lower would be very helpful. On my system (windows, P4 3.2 GHz) it's looking like they will take 4 hours or more apiece. I shut off the tap at 20 wus but even so, I can't afford to dedicate this system 100% to this project so several of mine will be past deadline. Good luck with 300! |
||
|
ID:
25 | Rating: 0
| rate:
/
|
||
Andre Kerstens
Forum moderator Project tester Volunteer tester 
Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0 |
||
|
That is actually a good idea. I've set it to 50 for now. Let's see what that does. No problem if you need to abort WUs or don't make the deadline: this is an alpha test to iron out problems with the system, we're not too interested in great results yet (although it is okay if we get some great results :-)
Good idea, setting the quota lower would be very helpful. On my system (windows, P4 3.2 GHz) it's looking like they will take 4 hours or more apiece. I shut off the tap at 20 wus but even so, I can't afford to dedicate this system 100% to this project so several of mine will be past deadline. Good luck with 300! |
||
|
ID:
26 | Rating: 0
| rate:
/
|
||
|
Hi all,
|
||
|
ID:
28 | Rating: 0
| rate:
/
|
||
|
Iam expecting 6h for 1 WU on my 3,2 P4 HT! |
||
|
ID:
30 | Rating: 0
| rate:
/
|
||
|
Thankfully looked at this board and went back and set my computer to 'no new work'. Seem to have got away with a mere 50 extra after the initial download of twelve. Estimated time 14min20sec, current execution 20.2% after 2h03min.
|
||
|
ID:
32 | Rating: 0
| rate:
/
|
||
|
Well, I got "only" 11 results on first Conroe.
|
||
|
ID:
43 | Rating: 0
| rate:
/
|
||
|
Well, I got "only" 11 results on first Conroe. How long have you been attached? If you noticed, I 'only' got 12 wu initially... |
||
|
ID:
45 | Rating: 0
| rate:
/
|
||
|
Well, I got "only" 11 results on first Conroe. perhaps changed, I got also too many and Iam attached to 35 now ;) |
||
|
ID:
46 | Rating: 0
| rate:
/
|
||
|
Well, I got "only" 11 results on first Conroe. I can top that: 39 for my good old AthlonXP2200+ for 0.1 days |
||
|
ID:
67 | Rating: 0
| rate:
/
|
||
|
Yup, same problem, got about 95 before I noticed and shut it down. So BOINC is estimating 15 minutes per work unit, which obviously isn't accurate, I'm 3 1/2 hours into 1 at about %30.... Only a P4 1.6
|
||
|
ID:
69 | Rating: 0
| rate:
/
|
||
|
on my sempron 3100+ my first WU took me 5h to crunch, and still have 19WU to go... everything would be alright, if tere was longer deadline.. 5 days is not enough to crunch it all (i suspect, i'll send results of 5-6 of them...) |
||
|
ID:
102 | Rating: 0
| rate:
/
|
||
|
95 as soon as I attatched. Took just over 5.5 hours for the first one to finish which of course errored out. The correction factor doesn't seem to have factored in at all and is still showing just over 6 minutes each.
|
||
|
ID:
134 | Rating: 0
| rate:
/
|
||
|
It would appear that I joined after all of you suggested a drop to 50 WU's a day. I received 100 (50 per cpu). I have not checked if all working as I had to go to work. |
||
|
ID:
136 | Rating: 0
| rate:
/
|
||
|
Has there been any word from the project about what to do with the excessive units?
|
||
|
ID:
151 | Rating: 0
| rate:
/
|
||
|
Andre Kerstens
Forum moderator Project tester Volunteer tester
Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0 |
||
|
Good question. We have discussed this in the team and the best thing probably is to abort these units. I have already cancelled a lot of wu's and stopped the wu generator until we have fixed the problem with the -131 error (we coded a fix yesterday and will test and deploy today if everything goes OK). So it might be people run out of work for a short while.
Has there been any word from the project about what to do with the excessive units? |
||
|
ID:
164 | Rating: 0
| rate:
/
|
||
|
this is why when I ALPHA test I set my preference to 0.08 days which is 1.92 hours or 115.2 minutes. Its not uncommon for a new project to have the fpops value not exaclty correct.
|
||
|
ID:
193 | Rating: 0
| rate:
/
|
||
|
this is why when I ALPHA test I set my preference to 0.08 days which is 1.92 hours or 115.2 minutes. Its not uncommon for a new project to have the fpops value not exaclty correct. Yeah, I normally do that too. Had reset it to 2 days though to get some extra for last weekend, I was going out of town away from a connection, and forgot to set it back :( -D |
||
|
ID:
238 | Rating: 0
| rate:
/
|
||
|
There is something seriously wrong with the work fetch for this project.
|
||
|
ID:
320 | Rating: 0
| rate:
/
|
||
|
Andre Kerstens
Forum moderator Project tester Volunteer tester
Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0 |
||
|
I'm going to post this to the boinc mailing lists, since boinc itself is supposed be handling the workfetch policy correctly. I'm not aware that we as a project can do something about it.
There is something seriously wrong with the work fetch for this project. |
||
|
ID:
321 | Rating: 0
| rate:
/
|
||
|
I'm going to post this to the boinc mailing lists, since boinc itself is supposed be handling the workfetch policy correctly. I'm not aware that we as a project can do something about it. Yep, I see it all the time too. I can understand it happening when there's no other work queued for those projects, but it seems to do it all the time. Almost as if whatever time period you've requested is being applied PER PROJECT instead of to the client as a whole... As in, I've seen it request 86400 seconds from BURP, and then immediately thereafter request only 24000 seconds from Chess960 - and it had units queued to chess, but not burp. Now, I've also noticed messages come back from time to time (from the project during a work request) saying you requested x amount of work, boinc on for yy percent of the time, this project gets zz percent of that, you won't finish in time. And it sends no work - so it seems the server *might* be able to make that determination somehow, but I don't know. It might also be a client generated message that just appears to come from the server - I haven't ethereal'd it so don't know conclusively. 5.4.11, btw, and only on Windows platforms (various xp/2000/2k3) -D |
||
|
ID:
323 | Rating: 0
| rate:
/
|
||
|
Yep, I see it all the time too. I can understand it happening when there's no other work queued for those projects, but it seems to do it all the time. Almost as if whatever time period you've requested is being applied PER PROJECT instead of to the client as a whole... I've never seen work requests behave any other way, at least in the last several revs of BOINC. It's always annoyed me because it tends to put BOINC in EDF when, imo, it shouldn't. Specifically, if BOINC requests work from a project (i.e. no EDF, uptime or LTD obstacles) -- and if that project has no work already queued on the host, I've never seen BOINC ask for less than a full cache of work for that project. No matter what else is queued for other projects. Assumed it was a "feature" as it's been true for so long. |
||
|
ID:
324 | Rating: 0
| rate:
/
|
||
|
Maybe Docking should send a max of 10 WUs. Last time I contacted the server I got 29. This is work for 3 days and I don`t WANT to stop all other Projekts because of Docking. |
||
|
ID:
326 | Rating: 0
| rate:
/
|
||
|
Maybe Docking should send a max of 10 WUs. Last time I contacted the server I got 29. This is work for 3 days and I don`t WANT to stop all other Projekts because of Docking.Sounds like a good idea. I'm quite sure SETI uses this method to limit fetching large portion of results at once (to prevent overloading servers). (it's a pain if you want to fetch full cache on a BOINC installation intended for non-internet machines...takes hours due to deffered communitation) |
||
|
ID:
333 | Rating: 0
| rate:
/
|
||
|
Maybe the estimated FLOPS are too low, and make BOINC think there is actually little work in the queue.
|
||
|
ID:
334 | Rating: 0
| rate:
/
|
||
|
Andre Kerstens
Forum moderator Project tester Volunteer tester
Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0 |
||
|
This seems to be a problem with the boinc client that is going to be fixed in the next release according to John Keck on the boinc_projects mailing list:
There is something seriously wrong with the work fetch for this project. ____________ D@H the greatest project in the world... a while from now! |
||
|
ID:
424 | Rating: 0
| rate:
/
|
||
|
I had noticed D@H wasn't recognizing my other cached work, so I have been leaving it set on "No new work" and lower my connection settings to 0.1 days before I allow more again. Even so, it still gives me 3 or 4 WU's (at 3 hours apiece).... but better than 300! :-O |
||
|
ID:
431 | Rating: 0
| rate:
/
|
||
|
Andre Kerstens
Forum moderator Project tester Volunteer tester
Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0 |
||
|
Make sure you mention this on the boinc_dev mailing list too, because that sounds like a bug in boinc itself. D@H has no clue about any of the other projects you are running; the boinc client handles that for us...
I had noticed D@H wasn't recognizing my other cached work, so I have been leaving it set on "No new work" and lower my connection settings to 0.1 days before I allow more again. Even so, it still gives me 3 or 4 WU's (at 3 hours apiece).... but better than 300! :-O ____________ D@H the greatest project in the world... a while from now! |
||
|
ID:
499 | Rating: 0
| rate:
/
|
||
|
Andre Kerstens
Forum moderator Project tester Volunteer tester
Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0 |
||
|
These are our current settings in config.xml:
Maybe the estimated FLOPS are too low, and make BOINC think there is actually little work in the queue. ____________ D@H the greatest project in the world... a while from now! |
||
|
ID:
500 | Rating: 0
| rate:
/
|
||
|
These are our current settings in config.xml: Client asks for workunits, server sends 50. If client asks again 10 seconds later, server would send another 50 (in this case it won't because of daily quota). If it asks before 10 seconds pass from last request, it will answer 'last RPC too recent'. Maybe you would want to lower max_wus_to_send so that it sends less workunits at a time. |
||
|
ID:
504 | Rating: 0
| rate:
/
|
||
|
Andre Kerstens
Forum moderator Project tester Volunteer tester
Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0 |
||
|
These are our current settings in config.xml: But isn't that dependent on the amount of work the client requests from the server as well? If it wants 8400 seconds of work, it shouldn't send 50, it should send 4 (example) if that would fit the request. I think this works okay, because that's what I see on my machine: I ask for 24 hours of work and I get 9 wus or so (every one takes about 2.5 hours). Andre ____________ D@H the greatest project in the world... a while from now! |
||
|
ID:
508 | Rating: 0
| rate:
/
|
||
|
Yeah, sure. That setting is the maximum number of workunits to send at a time. |
||
|
ID:
510 | Rating: 0
| rate:
/
|
||
|
suguruhirahara
Forum moderator Volunteer tester 
Joined: Sep 13 06 Posts: 282 ID: 15 Credit: 56,614 RAC: 0 |
||
|
Off-topic a bit, but I got what proves that this project is being tested with energy.
05/10/2006 21:02:05|Docking@Home|Sending scheduler request to http://docking.utep.edu/docking_cgi/cgi I've never seen such a message... It shows that everyone is crunching so hard, but please ready WUs for the platform (Windows x86), so that we can test the project more :) Thanks for reading, suguruhirahara ____________ 
I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions. |
||
|
ID:
848 | Rating: 0
| rate:
/
|
||
|
Andre Kerstens
Forum moderator Project tester Volunteer tester
Joined: Sep 11 06 Posts: 749 ID: 1 Credit: 15,199 RAC: 0 |
||
|
Off-topic a bit, but I got what proves that this project is being tested with energy. And that is great! 05/10/2006 21:02:05|Docking@Home|Sending scheduler request to http://docking.utep.edu/docking_cgi/cgi Our workgenerator doesn't monitor the database by itself yet, so we have to generate new workunits manually to make sure we don't run out of work and sometimes the level gets a bit low (although never to 0!). We are working on a wuGenerator that is a bit more intelligent and can do things by itself. Thanks Andre ____________ D@H the greatest project in the world... a while from now! |
||
|
ID:
852 | Rating: 0
| rate:
/
|
||
|
These are our current settings in config.xml: There is currently no setting for maximum number of results for a project that have not yet been processed on a particular project, however, that has been mentioned, and will probably be implemented. |
||
|
ID:
974 | Rating: 0
| rate:
/
|
||
|
suguruhirahara
Forum moderator Volunteer tester
Joined: Sep 13 06 Posts: 282 ID: 15 Credit: 56,614 RAC: 0 |
||
|
We are working on a wuGenerator that is a bit more intelligent and can do things by itself. Could you tell me when the generator will be introduced, in this alpha-phase or in the next beta-phase? I'd love my computers to crunch workunits much more, but they cannot as workunits for their platform are no longer ready... ____________
I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions. |
||
|
ID:
985 | Rating: 0
| rate:
/
|
||
|
I believe that this is something that needs to be fixed before we proceed to the next phase. We will post it on the news section.
|
||
|
ID:
987 | Rating: 0
| rate:
/
|
||
Message boards : Number crunching : Too Many WUs!
Database Error: The MySQL server is running with the --read-only option so it cannot execute this statement
array(3) {
[0]=>
array(7) {
["file"]=>
string(47) "/boinc/projects/docking/html_v2/inc/db_conn.inc"
["line"]=>
int(97)
["function"]=>
string(8) "do_query"
["class"]=>
string(6) "DbConn"
["object"]=>
object(DbConn)#44 (2) {
["db_conn"]=>
resource(168) of type (mysql link persistent)
["db_name"]=>
string(7) "docking"
}
["type"]=>
string(2) "->"
["args"]=>
array(1) {
[0]=>
&string(49) "update DBNAME.thread set views=views+1 where id=8"
}
}
[1]=>
array(7) {
["file"]=>
string(48) "/boinc/projects/docking/html_v2/inc/forum_db.inc"
["line"]=>
int(60)
["function"]=>
string(6) "update"
["class"]=>
string(6) "DbConn"
["object"]=>
object(DbConn)#44 (2) {
["db_conn"]=>
resource(168) of type (mysql link persistent)
["db_name"]=>
string(7) "docking"
}
["type"]=>
string(2) "->"
["args"]=>
array(3) {
[0]=>
object(BoincThread)#3 (16) {
["id"]=>
string(1) "8"
["forum"]=>
string(1) "2"
["owner"]=>
string(2) "23"
["status"]=>
string(1) "0"
["title"]=>
string(13) "Too Many WUs!"
["timestamp"]=>
string(10) "1160933024"
["views"]=>
string(4) "2639"
["replies"]=>
string(2) "38"
["activity"]=>
string(23) "1.5654448511493998e-129"
["sufferers"]=>
string(1) "0"
["score"]=>
string(1) "0"
["votes"]=>
string(1) "0"
["create_time"]=>
string(10) "1158128470"
["hidden"]=>
string(1) "0"
["sticky"]=>
string(1) "0"
["locked"]=>
string(1) "0"
}
[1]=>
&string(6) "thread"
[2]=>
&string(13) "views=views+1"
}
}
[2]=>
array(7) {
["file"]=>
string(63) "/boinc/projects/docking/html_v2/user/community/forum/thread.php"
["line"]=>
int(184)
["function"]=>
string(6) "update"
["class"]=>
string(11) "BoincThread"
["object"]=>
object(BoincThread)#3 (16) {
["id"]=>
string(1) "8"
["forum"]=>
string(1) "2"
["owner"]=>
string(2) "23"
["status"]=>
string(1) "0"
["title"]=>
string(13) "Too Many WUs!"
["timestamp"]=>
string(10) "1160933024"
["views"]=>
string(4) "2639"
["replies"]=>
string(2) "38"
["activity"]=>
string(23) "1.5654448511493998e-129"
["sufferers"]=>
string(1) "0"
["score"]=>
string(1) "0"
["votes"]=>
string(1) "0"
["create_time"]=>
string(10) "1158128470"
["hidden"]=>
string(1) "0"
["sticky"]=>
string(1) "0"
["locked"]=>
string(1) "0"
}
["type"]=>
string(2) "->"
["args"]=>
array(1) {
[0]=>
&string(13) "views=views+1"
}
}
}
query: update docking.thread set views=views+1 where id=8