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 Problems Thread |
No member browsing this thread |
Thread Status: Active Total posts in this thread: 254
|
Author |
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
... checked older rig too.... 30pph down to 20pph so it seems it is not rig specific. I'm getting the same picture here. I used to get broadly 33±3 pph (points-per-hour) for CFSW v6.05 or v6.09. With CFSW_v6.11, thus far, it's broadly 23±3 pph. My graphs on myGrid prove these downward-going ; [Edit 2 times, last edit by Former Member at Jun 11, 2012 12:51:35 PM] |
||
|
OldChap
Veteran Cruncher UK Joined: Jun 5, 2009 Post Count: 978 Status: Offline Project Badges: |
Just looked at some of today's completions on a 3770K (20 pages);
----------------------------------------All completion times are either 0.59 or 0.60 among the pendings is a variance of 12pts to 24.2pts claimed among the valids is a variance of 12.5 to 21.2 points claimed How does that work then??? I am used to the difference between claimed and granted but this.....????? This machine has thrown 1 error and no invalids according to the results status since I fixed an issue 2 days ago. My 2600K that has been error free for 12 months as far as I know gives me; All completion times are either 0.62 or 0.63 among the pendings is a variance of 12 to 21.3 points claimed among the valids is a variance of 12.1 to 19.6 points claimed This machine has thrown 1 error and 2 invalids according to the results status all of which were 2 days ago So, in order that I understand better how there can be such a variable amount claimed for the same work (time) could someone explain this?? and Have others seen sporadic errors or invalids on what was previously thought of as stable machines since the introduction of the short wu's?? Both rigs are running CFSW exclusively at this time |
||
|
kateiacy
Veteran Cruncher USA Joined: Jan 23, 2010 Post Count: 1027 Status: Offline Project Badges: |
I have not been seeing errors or invalids with the shorter WUs. Like you, I'm seeing very consistent runtimes but variable points claimed. From the small sample below, it looks as if the runtimes within batch (? first set of 4 numbers the same) are similar, but very different between batches.
----------------------------------------cfsw_ 3644_ 03644249_ 1-- kate-amd64 Pending Validation 6/11/12 05:25:32 6/11/12 19:33:12 0.75 28.0 / 0.0 cfsw_ 3644_ 03644345_ 1-- kate-amd64 Pending Validation 6/11/12 05:25:32 6/11/12 11:49:35 0.75 25.7 / 0.0 cfsw_ 3498_ 03498075_ 0-- kate-amd64 Valid 6/10/12 15:44:00 6/11/12 03:12:32 0.75 18.1 / 18.1 cfsw_ 3498_ 03498000_ 0-- kate-amd64 Valid 6/10/12 15:44:00 6/11/12 03:12:32 0.76 18.1 / 18.1 cfsw_ 3406_ 03406746_ 0-- kate-amd64 Valid 6/10/12 01:04:50 6/10/12 15:44:00 0.75 16.6 / 23.4 cfsw_ 3406_ 03406539_ 0-- kate-amd64 Valid 6/10/12 01:04:50 6/10/12 15:44:00 0.75 16.5 / 16.4 cfsw_ 3406_ 03406895_ 0-- kate-amd64 Valid 6/10/12 01:04:50 6/10/12 12:25:22 0.75 19.3 / 20.7 cfsw_ 3299_ 03299651_ 1-- kate-amd64 Valid 6/9/12 07:20:29 6/10/12 12:25:22 0.75 19.2 / 16.8 cfsw_ 3299_ 03299996_ 1-- kate-amd64 Valid 6/9/12 07:20:28 6/9/12 20:44:21 0.75 18.4 / 15.9 cfsw_ 3298_ 03298288_ 1-- kate-amd64 Valid 6/9/12 07:20:29 6/9/12 20:44:21 0.75 18.2 / 16.4 cfsw_ 3299_ 03299646_ 0-- kate-amd64 Pending Validation 6/9/12 07:20:29 6/9/12 20:44:21 0.74 18.0 / 0.0 |
||
|
pfm3136
Cruncher Joined: Apr 11, 2010 Post Count: 13 Status: Offline Project Badges: |
Same here, haven't checked all pc's, but for example my 2700K claims from 11 to 34 points for the same runtime of 0.62
---------------------------------------- |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Just to bring some closure to the problem (no work available message) I posted on the previous page, it seems to have worked itself out. It appears that the grid wouldn't let my rigs download more version 6.11 WU's until they crunched and reported some valid 6.11 WU's. My farm runs a 3 day queue so it spent a couple days asking for more work but hadn't returned any 6.11 WU's thus causing the "no work available" message.
|
||
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges: |
Yes, that's when 6.05 and 6.11 meet [and the fast with the now slow science app]. Had not expected for that to happen, with the app_plan under server 700, though not sure if this is also predicated on the client version. Might also be that it was disabled as the results of old and new science app are compatible, but strictly would have expected for the repair to be done with the 6.05 version. The 'homogenous app version' feature works well for assigning workunits consistently to the save app_version. However, if a computer already has an application version downloaded that is active and the server determines is suitable for running work on the host, then that version is used. Therefore, if we leave both the previous version and the new version active, computers that already have the old version will continue to use that version. In order to force computers to download the new version we have to mark the old version as inactive so that it is not considered for assignment. However, the server code still has a few bugs in how to handle workunits that are assigned to an inactive app version when the application has homogenous app version enabled. In this case, the output files are identical, so we simply do not have the feature enabled and thus there are some workunits that are matching between app versions. This is a short lived situation. |
||
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges: |
We are looking at the issues surrounding the inconsistent claims. The infrastructure that we had in place to make our estimated runtimes more consistent in the past may be making this worse with the new server code. It is going to take us a bit of time to understand how the dynamic is working and what we need to do in order to handle things best moving forward.
|
||
|
OldChap
Veteran Cruncher UK Joined: Jun 5, 2009 Post Count: 978 Status: Offline Project Badges: |
^Thanks for that.
----------------------------------------For all the fact that we crunch for the good of each project, there is a need for points to bear some relation to the effort (read equipment) and time spent progressing work units. I believe there is also a need to make such effort to be broadly similar between projects. When I say broadly similar, it would be great if consideration for power use be included in the calculation where a given machine often shows greater power use on one project compared to another. Perhaps I am moving into a line of wishful thinking but, in my opinion, things like this need to be considered for the greater good of any project |
||
|
Jim1348
Veteran Cruncher USA Joined: Jul 13, 2009 Post Count: 1066 Status: Offline Project Badges: |
When I say broadly similar, it would be great if consideration for power use be included in the calculation where a given machine often shows greater power use on one project compared to another. I think that might skew the results toward or away from some projects depending on a given chip technology, which changes over time anyway. We as the provider of the hardware should take care of that. I think the real job of the WCG team is to give us reasonably consistent credit for the scientific work done (total calculations required or whatever). Then we can decide, based upon that input, how to provide it in a cost effective manner, which includes not only equipment cost but running cost (i.e., electricity). Those factors will change over time and technology as chips change, and even as the electric rate changes (it has been going down for me). I think the WCG people can not possibly keep up with all those factors for everyone. Science and large distributed network projects are their thing, I hope. |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
For the past 24hrs or so, I've noticed improvements in consistency in the granting of credits for my CFSW_v6.11 doneWUs. The deviation is now lesser and tightly huddle around a central point -- at the 31±1.5 PPH (points-per-hour) point -- which is more in line with what I used to get in CFSW_v6.05/v6.09. Compare this to the 23±3 PPH point as reported in my earlier post , it is a vast improvement. Are others also seeing this improvement in consistency?
----------------------------------------; [Edit 1 times, last edit by Former Member at Jun 13, 2012 6:36:37 PM] |
||
|
|