| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: Computing for Sustainable Water Forum
Thread: Computing for Sustainable Water 64 bit Applications Released |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 31
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Think we'll let it ride and leave the techs to decide on on/off continues or periodic app purge... eventually the 6.11 will flush out.
In the mean time, CFSW beat HCC for the daily number one spot of results returned: CFCW: 313,456 > Per task 0.984 hours HCC: 296,677 > Per task 1.599 hours --//-- |
||
|
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges: 
|
Hi. I'm getting resends for 6.11 as well as the ones for the new 6.12, ( It keeps downloading the 6.11 app every time ) can't the app purge be turned off if for nothing else to save some bandwidth on both sides. The 'app purge' is a client side feature. I'm contacting David Anderson (BOINC) about what can be done about it. I'm guessing the only work around will be to update the 6.11 version to 6.12 for 32 bit but that will reset everyone's count of consecutive valid which is not ideal since it will generate a lot of resent results. |
||
|
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges:
|
Just another interesting job (well, at least for me...): W64 cfsw_ 4715_ 04715350_ 1-- 612 Valid 16.06.12 11:39:42 18.06.12 11:07:00 0.69 20.3 / 20.2 W64 cfsw_ 4715_ 04715350_ 2-- 612 Valid 16.06.12 11:39:10 16.06.12 12:53:56 1.06 20.1 / 20.2 W32 cfsw_ 4715_ 04715350_ 0-- 611 Error 16.06.12 10:26:11 16.06.12 10:38:02 0.00 20.8 / 0.0 The WU must have started as w32, since the _0 job had app version 6.11. But it returned as error before the second job (minimum quorum 2) was sent. And then it decided to send the remaining job and the repair job both with version 6.12 - maybe because the first job returned an error and therefore didn't need to be matched? Impressive... When the transitioner evaluates the state of a workunit, and if there are no results returned successfully and no results currently in progress, then if additional copies of the workunit need to be created (so that they can be distributed) it will reset both the homogenous_redundancy settings and the homogenous_app_version settings so that the workunit can be sent to any computers that can run the application. This is what happened in the case of your workunit. |
||
|
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges:
|
As far as 64 bit machines being assigned 32 bit workunits and running the 32 bit app version. The logic for finding work to run is as follows:
1) Find results that the computer can run that require a 'reliable' host 2) Find results that the computer can run that were previously considered by another computer that the other computer could not run 3) Find any result that the computer can run In all cases, the users preference for which applications are allowed is honored. In cases #1 and #2 a computer that prefers 64 bit application versions could be assigned to run a result using a 32 bit application version. A 'wingman' is a common cause for #2. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Yes "Results" and "Task" assignment are in context the same thing [but the questioner seemed, on second thought, to have come to the same conclusion] and then deleted the post before a reply could be posted. ;P
--//-- |
||
|
|
Eurwin
Cruncher Joined: Apr 28, 2007 Post Count: 17 Status: Offline Project Badges:
|
Hello SeKeRob,
----------------------------------------You were interested in the different runtime between the 32bit and the 64bit version on the same machine? This is what’s the case for my machine, an Phenom II X6 1090T , 8GB RAM. In 32bit it teaks between 40 and 45 minutes , in 64bit it’s done in 35 minutes :-) So I like the upgrade ;-) Greetings edit: I'm running on windows 7 premium [Edit 1 times, last edit by Eurwin at Jun 18, 2012 6:17:42 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
That's quite a bit more than the gain I measured under Linux from 6.11 to 6.12 running on a 64 bit OS. WUprop maybe has some interesting stats to share for you: http://wuprop.boinc-af.org/results/duree.py?f...p;tri=projet&sort=asc
----------------------------------------[ot]edit: Oddly, my octo runs the 64 bit .25 hours faster than WUprop shows, range 1.3-1.5, where I'm getting 1.05-1.07, so let that project run a bit on the side [uses 12 seconds on 4 hours wallclock time to capture WU stats]. Their charts update real time, so my device should be visible in this chart fairly soon: http://wuprop.boinc-af.org/results/graph_dure...teforme=all&cpuid=989 ... mind you this thing runs way faster [and hotter] since it's set to ''performance'' instead of ''coolest''.[/ot] --//-- [Edit 1 times, last edit by Former Member at Jun 18, 2012 6:18:33 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Those that don't like old apps being deleted, the 32 bits e.g. no longer used becausee the client only runs 64 bits, will want to test 7.0.30 [it's test, yes]. This one needs you to put your glasses on and be read twice, at least:
----------------------------------------client: it's possible for a host to get app versions for a given app that have different platforms and different version #s. The client was erroneously deleting the one w/ the lower version when it was no longer in use. Fix: in garbage collection, consider one version to supercede [sic] another only if they have the same platform. The key interpretative left is the definition of platform. If it's meant to express 32 bit and 64 bits, then the 6.11 32 bit would not get removed when there's only 6.12 64 bit tasks on a 64 bit system. We'll find out on the next occasion when a 32 bit gets upgraded and the user happens to have 7.0.30 or higher, and is familiar with the issue.  --//-- [Edit 1 times, last edit by Former Member at Jun 29, 2012 12:35:12 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
fao knreed: To follow on to testing with 7.0.30, had 6.11 32 bit and 6.12 64 bit in queue and forced them to deplete so none were left. Reported and got new, but confusingly, of 6.11 and 6.12 again, both with 10 day deadline AND in the same work-call.
----------------------------------------6.12 cfsw cfsw_6880_06880974_0 - (-) 0,00 0,000 01:13:11 09d,22:48:11 1-7-2012 9:02:28 Ready to start 6.12 cfsw cfsw_6880_06880975_0 - (-) 0,00 0,000 01:13:11 09d,22:48:11 1-7-2012 9:02:28 Ready to start 6.11 cfsw cfsw_6880_06880076_1 - (-) 0,00 0,000 01:02:08 09d,22:48:11 1-7-2012 9:02:28 Ready to start 6.11 cfsw cfsw_6880_06880887_1 - (-) 0,00 0,000 01:02:08 09d,22:48:11 1-7-2012 9:02:28 Ready to start 6.11 cfsw cfsw_6880_06880102_1 - (-) 0,00 0,000 01:02:08 09d,22:48:11 1-7-2012 9:02:28 Ready to start The message log does not indicate a re-downloading of the 6.11 32 bits app, just task .job and .zip files, so that issue seems fixed with this client version, but why the mix of 32 and 64 bit? Not seen an answer, but is WCG now testing to discover which of the 2 runs faster on any given host and locks in the fastest app after 10-20 whatever? If so, how many are there in the comparative test? The 64 bits runs quite a bit faster as can be seen from this small selection, .08 to .10 hours or about 5-6 minutes, which on an hour run time is significant. World Community Grid 6.12 cfsw cfsw_6738_06738010_1 01:07:09 (01:03:42) 30-6-2012 23:47:39 1-7-2012 0:03:04 94,86 Reported: OK World Community Grid 6.12 cfsw cfsw_6710_06710739_0 01:03:43 (01:02:41) 30-6-2012 22:40:29 1-7-2012 0:03:04 98,38 Reported: OK World Community Grid 6.11 cfsw cfsw_6674_06674320_1 01:11:28 (01:10:31) 30-6-2012 19:03:32 30-6-2012 21:11:54 98,67 Reported: OK World Community Grid 6.12 cfsw cfsw_6705_06705605_0 01:03:29 (01:02:35) 30-6-2012 16:32:56 30-6-2012 17:33:02 98,58 Reported: OK World Community Grid 6.11 cfsw cfsw_6674_06674534_2 01:13:05 (01:12:00) 30-6-2012 15:31:15 30-6-2012 15:37:16 98,52 Reported: OK World Community Grid 6.12 cfsw cfsw_6684_06684187_0 01:13:34 (01:12:03) 30-6-2012 15:29:28 30-6-2012 15:37:16 97,94 Reported: OK From that perspective, really like to only receive 6.12 unless there is need for a repair, if there is homogeneity requirement [Thought to have read there was not] Thx --//-- edit: The 5 newly assigned tasks of 6.11 and 6.12 forced ahead and completed, with little doubt that 6.12 is faster. 6.11 cfsw cfsw_6880_06880887_1 01:15:03 (01:13:44) 1-7-2012 11:37:10 1-7-2012 12:11:37 98,25 Reported: OK 6.11 cfsw cfsw_6880_06880076_1 01:14:40 (01:14:01) 1-7-2012 11:36:48 1-7-2012 12:11:37 99,13 Reported: OK 6.11 cfsw cfsw_6880_06880102_1 01:14:38 (01:13:08) 1-7-2012 11:36:42 1-7-2012 12:11:37 97,99 Reported: OK 6.12 cfsw cfsw_6880_06880974_0 01:08:37 (01:07:30) 1-7-2012 11:30:47 1-7-2012 12:11:37 98,37 Reported: OK 6.12 cfsw cfsw_6880_06880975_0 01:06:52 (01:05:51) 1-7-2012 11:29:01 1-7-2012 12:11:37 98,48 Reported: OK Whilst the work fetch was suspended, forced reporting to clear out all CFSW, then one minute later forced another update. If the "don't retain older app" nolonger applies, expecting to see new 6.11 app download. For the moment these 2 are still in the WCG project folder i.e. no gunk cleaning has taken place, though now a 6.12 has arrived. wcgrid_cfsw_baygame_6.11_windows_intelx86 wcgrid_cfsw_baygame_prod_gfx.exe.6.11 P.S. Noted the change of the naming convention. exe is included and version number at end. [Edit 1 times, last edit by Former Member at Jul 1, 2012 10:24:51 AM] |
||
|
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges:
|
When the scheduler loops through the results to send in the shared memory segment, it will first look for results that already have an hr_class assigned or have been rejected by some other computer. This is done to ensure that the shared memory segment has as many results ready to be sent to any platform as possible.
Since a 64 bit computer is capable of running a 32 bit application version, it can be assigned the wingman copy of a workunit that has already been targeted for the 32 bit platform. I haven't gone to look to confirm, but I would guess that in all cases where you are assigned a 32 bit app version with a full deadline, yours would be the 2nd copy assigned. Take a look and let me know if that is what you see. |
||
|
|
|