Deadlines are very short.


Advanced search

Message boards : Number crunching : Deadlines are very short.

Sort
Author Message
Profile adrianxw
Volunteer tester
Avatar

Joined: Dec 30 06
Posts: 164
ID: 343
Credit: 1,669,741
RAC: 0
Message 4109 - Posted 25 Jun 2008 19:57:35 UTC

As the title says, the deadlines are very short for this run.
____________
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

ID: 4109 | Rating: 0 | rate: Rate + / Rate - Report as offensive
Profile Conan
Volunteer tester
Avatar

Joined: Sep 13 06
Posts: 219
ID: 100
Credit: 4,256,493
RAC: 0
Message 4118 - Posted 26 Jun 2008 4:29:15 UTC - in response to Message ID 4109 .

As the title says, the deadlines are very short for this run.


> Yes that's true, I assume this is so test work units can be returned quickly to see if there are any problems and fix them quickly if there is.
One problem that I can see is that because the deadlines are so short my computers run them in "High Priority" mode and the check-pointing feature does not get tested on my computers, even if the WU runs for 5 hours (as it does on Linux).
____________
ID: 4118 | Rating: 0 | rate: Rate + / Rate - Report as offensive
Profile adrianxw
Volunteer tester
Avatar

Joined: Dec 30 06
Posts: 164
ID: 343
Credit: 1,669,741
RAC: 0
Message 4122 - Posted 26 Jun 2008 16:37:29 UTC

Credit is really miserly as well I see, most of the projects running on this quad are turning in 20+ credits per core per hour, the last Docking wu I crunched gave 12!
____________
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

ID: 4122 | Rating: 0 | rate: Rate + / Rate - Report as offensive
Profile Arun
Volunteer tester

Joined: Apr 30 08
Posts: 40
ID: 379
Credit: 10,385
RAC: 0
Message 4124 - Posted 26 Jun 2008 18:27:56 UTC - in response to Message ID 4109 .

As the title says, the deadlines are very short for this run.


We have created more workunits and have increased the deadline to 5 days.

Thanks for your feedback and help.

Arun
ID: 4124 | 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 4126 - Posted 26 Jun 2008 18:55:49 UTC - in response to Message ID 4124 .

We have created more workunits and have increased the deadline to 5 days.


Just picked up 2 of them, first is running in high priority mode at this moment, but I think that's because of the "Task duration correction factor" of my host.
It thinks that the wu will take about 16 hours, but 3 hours will be more accurate.

Time will cure that issue...

;-)
____________
ID: 4126 | Rating: 0 | rate: Rate + / Rate - Report as offensive
BobCat13
Volunteer tester

Joined: Nov 14 06
Posts: 22
ID: 239
Credit: 285,322
RAC: 0
Message 4127 - Posted 26 Jun 2008 19:21:02 UTC - in response to Message ID 4126 .

Rene Oskam wrote:
Just picked up 2 of them, first is running in high priority mode at this moment, but I think that's because of the "Task duration correction factor" of my host. It thinks that the wu will take about 16 hours, but 3 hours will be more accurate.

Time will cure that issue...

;-)

Unless the <rsc_fpops_est> for each ligand type is set closer to the actual amount, time will not cure that issue. The 1tng WUs are set too high and the 1abe WUs are set too low. Following are the numbers that would get the DCF closer to 1 instead of having it jump around when running a mix of 1tng and 1abe.

1abe is issued with a setting of 10,000,000,000,000.000000 (I added the commas) when a much closer estimate is 18,000,000,000,000.000000

1tng is issued with a setting of 52,558,670,000,000.000000 but actually is closer to 20,600,000,000,000.000000

A single 1abe task will cause the DCF to jump somewhere up around 1.8 or higher and since the 1tng is already estimated at 2.5 times it's real runtime, now the 1.8 DCF will cause it to estimate at almost 5 times the correct runtime.

I use a 16 hour buffer and boinc will only download 2 1tng tasks because the high fpops_est cause it to estimate each task at 8:27 when it only takes about 1:52. On the other hand if it grabs only 1abe tasks then it gets too many because the low fpops_est cause an estimate of 0:43 when it really takes approximately 1:36.
ID: 4127 | 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 4128 - Posted 26 Jun 2008 19:35:31 UTC - in response to Message ID 4127 .

Unless the <rsc_fpops_est> for each ligand type is set closer to the actual amount, time will not cure that issue.

<snip>

On the other hand if it grabs only 1abe tasks then it gets too many because the low fpops_est cause an estimate of 0:43 when it really takes approximately 1:36.


That's why I used "Time will cure that issue..."

I'm sure that, with the help of usefull replies like yours, the project team will be able to tackle issues like this.

;-)

____________
ID: 4128 | Rating: 0 | rate: Rate + / Rate - Report as offensive
Profile Arun
Volunteer tester

Joined: Apr 30 08
Posts: 40
ID: 379
Credit: 10,385
RAC: 0
Message 4132 - Posted 26 Jun 2008 23:38:44 UTC - in response to Message ID 4127 .

Rene Oskam wrote:
Just picked up 2 of them, first is running in high priority mode at this moment, but I think that's because of the "Task duration correction factor" of my host. It thinks that the wu will take about 16 hours, but 3 hours will be more accurate.

Time will cure that issue...

;-)

Unless the <rsc_fpops_est> for each ligand type is set closer to the actual amount, time will not cure that issue. The 1tng WUs are set too high and the 1abe WUs are set too low. Following are the numbers that would get the DCF closer to 1 instead of having it jump around when running a mix of 1tng and 1abe.

1abe is issued with a setting of 10,000,000,000,000.000000 (I added the commas) when a much closer estimate is 18,000,000,000,000.000000

1tng is issued with a setting of 52,558,670,000,000.000000 but actually is closer to 20,600,000,000,000.000000

A single 1abe task will cause the DCF to jump somewhere up around 1.8 or higher and since the 1tng is already estimated at 2.5 times it's real runtime, now the 1.8 DCF will cause it to estimate at almost 5 times the correct runtime.

I use a 16 hour buffer and boinc will only download 2 1tng tasks because the high fpops_est cause it to estimate each task at 8:27 when it only takes about 1:52. On the other hand if it grabs only 1abe tasks then it gets too many because the low fpops_est cause an estimate of 0:43 when it really takes approximately 1:36.


Thanks for your feedback. Your estimates are very good. We will be distributing 1tng and 1abe for 320 conformations and 20 rotations with these flops (+10%) from next time.

1tng - 22,000,000,000,000
1abe - 20,000,000,000,000

We are doing testing using these FLOPS count.

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

Message boards : Number crunching : Deadlines are very short.

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)#13 (2) {
      ["db_conn"]=>
      resource(78) 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=314"
    }
  }
  [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)#13 (2) {
      ["db_conn"]=>
      resource(78) of type (mysql link persistent)
      ["db_name"]=>
      string(7) "docking"
    }
    ["type"]=>
    string(2) "->"
    ["args"]=>
    array(3) {
      [0]=>
      object(BoincThread)#3 (16) {
        ["id"]=>
        string(3) "314"
        ["forum"]=>
        string(1) "2"
        ["owner"]=>
        string(3) "343"
        ["status"]=>
        string(1) "0"
        ["title"]=>
        string(25) "Deadlines are very short."
        ["timestamp"]=>
        string(10) "1214523524"
        ["views"]=>
        string(3) "592"
        ["replies"]=>
        string(1) "7"
        ["activity"]=>
        string(20) "1.0730933782878e-102"
        ["sufferers"]=>
        string(1) "0"
        ["score"]=>
        string(1) "0"
        ["votes"]=>
        string(1) "0"
        ["create_time"]=>
        string(10) "1214423855"
        ["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) "314"
      ["forum"]=>
      string(1) "2"
      ["owner"]=>
      string(3) "343"
      ["status"]=>
      string(1) "0"
      ["title"]=>
      string(25) "Deadlines are very short."
      ["timestamp"]=>
      string(10) "1214523524"
      ["views"]=>
      string(3) "592"
      ["replies"]=>
      string(1) "7"
      ["activity"]=>
      string(20) "1.0730933782878e-102"
      ["sufferers"]=>
      string(1) "0"
      ["score"]=>
      string(1) "0"
      ["votes"]=>
      string(1) "0"
      ["create_time"]=>
      string(10) "1214423855"
      ["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=314