| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: Discovering Dengue Drugs - Together - Phase 2 Forum
Thread: New thread for It's raining Dengue, Hallelujah!... |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 2370
|
|
| Author |
|
|
Crystal Pellet
Veteran Cruncher Joined: May 21, 2008 Post Count: 1320 Status: Offline Project Badges: 
|
seippel wrote:
The current drought is over and more rain is on the way! These are typeC work units for dg01. In total there are 108207 (two copies of each will be sent out). The final batch is dg01_d_g49_d81_to_d490. Enjoy! I have no idea how the batches are numbered and/or distributed. Until now all tasks I got are from dg01 batches: a041-a050 a081-a090 a311-a320 a341-a350 |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Don´t know what the issue is, but seen it now in multiple rains: The Linux quad gets to cache per setting with hands down and on same profile Windows 7 is having a hard time... not even a half dozen.
----------------------------------------Anyway, we´re on the move again... 12 days worth of CPU time in the coffers. Crunch on --//-- P.S. An a342 is the last in the list... 200,000 plus we´ll be crunching this time around... and the 16MB files did come down to the outback at speeds up to 350Kbps late last evening. edit: now the spacebaris really broken. [Edit 1 times, last edit by Former Member at Jul 19, 2011 7:02:04 AM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Suddenly the half dozen doubled and then looked on the RS pages for the DDDT2's. One showing with:
<error_code>-200</error_code> Looks familiar and 3 wingman had same :( , circulation stopped... maybe just one bad build unit. Message log shows: 19-07-2011 09:36 [sched_op_debug] Reason: Unrecoverable error for result dg01_a348_pr45a1_2 (WU download error: couldn't get input files:<file_xfer_error> <file_name>dg01_a_g35_a341_to_a350_typeC_a348.rtf.gzb</file_name> <error_code>-200</error_code></file_xfer_error>) No computing time wasted :D --//-- |
||
|
|
kskjold
Senior Cruncher Norway Joined: May 20, 2008 Post Count: 469 Status: Offline Project Badges: 
|
24 wu's are returned. 7 is valid and 17 are in PV. Everything works fine....
---------------------------------------- |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Now that I've got a good lot, 3 days worth on the quad, noticed that all C Type subs have the same completion time projection... the Sx same as the Pc, i.e. the stockpile is overestimated and DCF's will be doing their wild dance again ... Would that also work as sending beggings for more rain ;?
----------------------------------------Just added a day to the cache size setting to compensate :O --//-- edit: insert "beggings" [Edit 1 times, last edit by Former Member at Jul 19, 2011 9:36:04 AM] |
||
|
|
Crystal Pellet
Veteran Cruncher Joined: May 21, 2008 Post Count: 1320 Status: Offline Project Badges:
|
Adding a day to your cache size -> Does that mean, you expect this is not the monsoon rain :)
|
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Well, seippel did say ~216k WU's. That gets lapped up rather much quicker with the superbly improved download times... and I'd like to step away from micromanaging too... just let it crunch unattended in that far and hotter corner.
--//-- |
||
|
|
kskjold
Senior Cruncher Norway Joined: May 20, 2008 Post Count: 469 Status: Offline Project Badges:
|
But doesn't large cache increasing the returning time of the work to the scientists? If everyone working with a cache below 2 days, the rain will last a little longer, but the scientists will receiving the wu's quicker. Isn't that correct? And the next rain will come quicker, it is a win win situation......
----------------------------------------  |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
But doesn't large cache increasing the returning time of the work to the scientists? If everyone working with a cache below 2 days, the rain will last a little longer, but the scientists will receiving the wu's quicker. Isn't that correct? And the next rain will come quicker, it is a win win situation...... Yes and No. For A/B type a quick return is must [hence priortiy and shorter deadline setting]. For C Type not so much since they're not a base for further work generation. Aside QA control, they wont look that hard at the data until the dg01 run [one of 18 targets] is completing. Think 1 day up to make it a 4 day return for the tail end is no drama, the initial work cached still completed fast, then shrinking to total quick as I've got many sq/sr WU's with long hours when known to do 1.5-2 hours. But, yes, if we'd all run short caches, the stream will be longer and the farm owners will be doing their years whilst the 1-2 device crunchers are scraping the barrel till the next run. So, permit me to take a little ego headway on this run ;O) --//-- NB: Who knows with the Download Bandwidth issue out of the way, the stream will be going more steady, and then that will give all a sign, to not nervously temple near the tits of the hoppers. |
||
|
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges: 
|
Suddenly the half dozen doubled and then looked on the RS pages for the DDDT2's. One showing with: <error_code>-200</error_code> Looks familiar and 3 wingman had same :( , circulation stopped... maybe just one bad build unit. - We are looking at this. The multi-threaded app that loads the work into BOINC appears to have a concurrency issue. Here is the issue: For each file that is 'precompressed' (i.e. the .gzb files), the load application copies and compresses the file to the download directory. It then creates a file that stores the uncompressed file size and uncompressed md5sum. Once the app has moved all of the files in place, it then calls the BOINC code to add the workunit to the database. That process looks for the file with the size and md5sum. If it doesn't find that file, then it computes those from the file itself. That part is unmodified BOINC code. This works if the file is not precompressed for storage on the filesystem and for transfers (and then automatically decompressed during download by BOINC). However, it appears that in some cases where workunits share files, some workunits are being loaded into BOINC without the md5sum/file size file being there. Thus BOINC is computing the compressed size and md5sum when it loads the workunit but the client checks those values against the uncompressed file size and md5sum. This generates an error and the client rejects the workunit. It is only happening on about 0.7% of workunits for dddt2 only. We are trying to figure out what is going on now. |
||
|
|
|