"High Priority" Strikes Again


Advanced search

Message boards : Number crunching : "High Priority" Strikes Again

Sort
Author Message
Steven Meyer
Avatar

Joined: May 26 09
Posts: 23
ID: 12091
Credit: 130,335
RAC: 0
Message 5057 - Posted 2 Jun 2009 12:47:24 UTC

I recently started crunching for Docking@Home as a second project, S@H being my first.

Docking@Home has repeatedly fetched a large stack of work units, all of which are due in such a short amount of time that all of them are required to run "High Priority" in order to get all of them done in time.

This cheats other projects out of their share of CPU time, and puts D@H into a large amount of Debt in relationship to other projects.

In order to remedy the problem by reducing the work load from D@H, I have had to abort dozens of D@H work units.

Something needs to be done to reduce the number of D@H work units fetched or else increase the time allowed to complete them so that the work load is not so heavy that "High Priority" is required to get the job done in time.

____________

ID: 5057 | Rating: 0 | rate: Rate + / Rate - Report as offensive
Rene
Volunteer tester
Avatar

Joined: Oct 2 06
Posts: 121
ID: 160
Credit: 109,415
RAC: 0
Message 5065 - Posted 5 Jun 2009 20:08:47 UTC

Something needs to be done to reduce the number of D@H work units fetched or else increase the time allowed to complete them so that the work load is not so heavy that "High Priority" is required to get the job done in time.


Once your DCF has leveled to the correct factor, running docking besides seti shouldn't be a problem.
You can also set the time to connect at a smaller amount (e.g. 0,1) to decrease the amount of units to be downloaded.

;-)
____________
ID: 5065 | Rating: 0 | rate: Rate + / Rate - Report as offensive
Odd-Rod

Joined: Sep 3 08
Posts: 2
ID: 485
Credit: 27,955
RAC: 0
Message 5067 - Posted 7 Jun 2009 14:01:02 UTC - in response to Message ID 5057 .


This cheats other projects out of their share of CPU time, and puts D@H into a large amount of Debt in relationship to other projects.

This sentence mentions the problem and the 'answer'. Yes, it will deprive other projects of their share in the shorter term, but the large amount of Debt will mean that it (eventually) won't fetch work here, and will 'pay back' the debt.

Please note, I'm not defending Boinc's actions here, just pointing out that resource share is only honoured over a long term, not the way many of us would prefer.

Regards
Rod
ID: 5067 | Rating: 0 | rate: Rate + / Rate - Report as offensive
Rene
Volunteer tester
Avatar

Joined: Oct 2 06
Posts: 121
ID: 160
Credit: 109,415
RAC: 0
Message 5068 - Posted 7 Jun 2009 15:51:39 UTC - in response to Message ID 5067 .

Please note, I'm not defending Boinc's actions here, just pointing out that resource share is only honoured over a long term, not the way many of us would prefer.

Regards
Rod


Lucky for you BOINC needs no defending here... ;-)

Adding a project tends to "mess up" things sometimes, although mostly it's caused by either a short time to report or a miscalculation of the time to finish a wu.
As you stated in the long run BOINC will come to a "fair" recource share.

What users could do is, keep in mind that (when a project has a rather short time to finish a result) decreasing the "time to report" from 2 days to a lesser amount will never do any harm. Reading the boards can help in matters like this.

So in short... also the user can do it's share in "damage control".

____________
ID: 5068 | Rating: 0 | rate: Rate + / Rate - Report as offensive
Profile robertmiles

Joined: Apr 16 09
Posts: 96
ID: 9967
Credit: 1,290,747
RAC: 0
Message 5649 - Posted 16 Jan 2010 13:15:16 UTC

A suggestion for how to offer at least some control of this situation:

Assume that newly connected computers which have not returned any successful workunits for your project do not have sufficient data to calculate the correct DCF yet; and therefore limit the number of workunits they can have in progress.

If the first workunit they return is valid, assume that they now have a correct DCF and this restriction can be removed. If they return a few invalid workunits first, it's unclear how fast to remove the restriction after they return at least one valid workunit.

ID: 5649 | Rating: 0 | rate: Rate + / Rate - Report as offensive

Message boards : Number crunching : "High Priority" Strikes Again

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)#10 (2) {
      ["db_conn"]=>
      resource(72) of type (mysql link persistent)
      ["db_name"]=>
      string(7) "docking"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(1) {
      [0]=>
      &string(51) "update DBNAME.thread set views=views+1 where id=435"
    }
  }
  [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)#10 (2) {
      ["db_conn"]=>
      resource(72) of type (mysql link persistent)
      ["db_name"]=>
      string(7) "docking"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(3) {
      [0]=>
      object(BoincThread)#3 (16) {
        ["id"]=>
        string(3) "435"
        ["forum"]=>
        string(1) "2"
        ["owner"]=>
        string(5) "12091"
        ["status"]=>
        string(1) "0"
        ["title"]=>
        string(29) ""High Priority" Strikes Again"
        ["timestamp"]=>
        string(10) "1263647716"
        ["views"]=>
        string(3) "200"
        ["replies"]=>
        string(1) "4"
        ["activity"]=>
        string(19) "3.9285882413663e-79"
        ["sufferers"]=>
        string(1) "0"
        ["score"]=>
        string(1) "0"
        ["votes"]=>
        string(1) "0"
        ["create_time"]=>
        string(10) "1243946844"
        ["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(3) "435"
      ["forum"]=>
      string(1) "2"
      ["owner"]=>
      string(5) "12091"
      ["status"]=>
      string(1) "0"
      ["title"]=>
      string(29) ""High Priority" Strikes Again"
      ["timestamp"]=>
      string(10) "1263647716"
      ["views"]=>
      string(3) "200"
      ["replies"]=>
      string(1) "4"
      ["activity"]=>
      string(19) "3.9285882413663e-79"
      ["sufferers"]=>
      string(1) "0"
      ["score"]=>
      string(1) "0"
      ["votes"]=>
      string(1) "0"
      ["create_time"]=>
      string(10) "1243946844"
      ["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=435