| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
| World Community Grid Forums
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 822
|
|
| Author |
|
|
rendition54
Master Cruncher USA Joined: Aug 16, 2005 Post Count: 2609 Status: Offline Project Badges:
|
Today i moved 30 CPU threads from OPN1 to other CPU projects. I hope this helps increase the OPNG WU availability.
----------------------------------------![]() |
||
|
|
Amalthea
Cruncher Joined: Sep 13, 2020 Post Count: 8 Status: Offline Project Badges:
|
Individually removing our computers from Open Pandemics CPU tasks is pointless. The tasks are created and will be assigned to somebody. If you don't waste your threads, somebody else will. Knreed wrote about avoiding OPN becoming an intermittent project. I thought that was a curious thing to say. Maybe feast-or-famine tasks are harder on the system, or harder to manage, or even result in too many forum posts to moderate as people discuss getting work, constantly bicker, and troubleshoot out-of-work messages? In every recent project update, there is less than a month of MCM batches in the queue. I've been saying from the start that we need to shift 100% of this project to the GPUs to free up massive CPU computation for other projects. Now that the Microbiome Immunity project is ending, we're talking 280 years of crunching power a day, with one project big enough to absorb the demand. But maybe it's not big enough; maybe that would be enough to make MCM batches become intermittent? Is that a problem worth avoiding? Would WCG staff, or crunchers mind if every project backlog ran dry? Do we mind so much as to be willing to run millions of low priority work units to keep the supply stable? Sup! Well I don't know where you get those numbers from, like, 280 years of computing power a day, but if you check the statistics it used to be about 40 years, now it grew to about 60 years each day. Your numbers are a tad closer to mapping cancer markers, but that ain't ending just yet. Cheers, Amal [Edit 1 times, last edit by Amalthea at Jun 14, 2021 12:18:25 PM] |
||
|
|
hnapel
Advanced Cruncher Netherlands Joined: Nov 17, 2004 Post Count: 82 Status: Offline Project Badges:
|
... I would ask that if you are someone who has only OpenPandemics selected, please consider adding Mapping Cancer Markers and/or the African Rainfall Project in addition to OpenPandemics. OpenPandemics will continue at the same pace regardless of how much CPU power is allocated to it as the GPU side will pick up any slack left over from the CPU side. But from what you explained this would not be a manual process right? If more people would heed this request you would see less CPU demand so you can tweak the number of GPU batches to a higher value? Personally I have added ARP to the mix (on a few PCs) and reduced the overall CPU % on them and of course allowing GPU work if it arrives. Bottom line is of course the project has more power than the science processing can handle, they may need to think about if any of that processing can be parallelized to submit it to the volunteers as well! Also for people who do it for the glory of badge hunting (which is based on processing time) this is a bummer, you may thus also want to rethink the whole badge system to reward the points which actually is a better metric for contributed effort. [Edit 1 times, last edit by hnapel at Jun 14, 2021 1:15:39 PM] |
||
|
|
Mike.Gibson
Ace Cruncher England Joined: Aug 23, 2007 Post Count: 12594 Status: Offline Project Badges:
|
Looking at the statistics, yesterday the total run time was 546 years of which 34 was MIP (down from over 60 years per day since the announcement). As this was only 10% of total crunching the slack should easily be able to be absorbed by other projects. However, the next project to finish might be a different matter without new work.
There is still supposed to be a project coming along but how long that will take is anyone's guess. Mike |
||
|
|
adriverhoef
Master Cruncher The Netherlands Joined: Apr 3, 2009 Post Count: 2346 Status: Offline Project Badges:
|
Looking at the statistics, yesterday the total run time was 546 years of which 34 was MIP (down from over 60 years per day since the announcement) No, Mike. 34 (or rather a little less than 33½) years for MIP1 is only half a day's worth of statistics. ![]() |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Yesterday, MIP's share was 64 years.
|
||
|
|
adriverhoef
Master Cruncher The Netherlands Joined: Apr 3, 2009 Post Count: 2346 Status: Offline Project Badges:
|
you may thus also want to rethink the whole badge system to reward the points which actually is a better metric for contributed effort. If you need 24 hours to complete a task, that's your contributed effort. And so it follows that time is your contributed effort. Points or credits are the reward you get for your contribution, they aren't a contributed effort, they are the result of your contribution. If you wouldn't get points and you wouldn't get badges for runtime, you wouldn't be awarded anything. Suppose you wouldn't get points, then you would still get badges based on runtime. Now, the situation is that you get points AND badges for your contribution. They are two different things. You can't express contributed effort in points. They are two different things. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Looking at the statistics, yesterday the total run time was 546 years of which 34 was MIP (down from over 60 years per day since the announcement). As this was only 10% of total crunching the slack should easily be able to be absorbed by other projects. However, the next project to finish might be a different matter without new work. There is still supposed to be a project coming along but how long that will take is anyone's guess. Mike The problem is, once MIP finishes, you only have MCM to absorb the extra crunching capacity. HST is VERY limited, they are trying to throttle back OPN, ARP is limited due to size of the data, that only leaves MCM. If SCC comes back, they should come back using the GPU version [Edit 1 times, last edit by Former Member at Jun 14, 2021 3:52:41 PM] |
||
|
|
hnapel
Advanced Cruncher Netherlands Joined: Nov 17, 2004 Post Count: 82 Status: Offline Project Badges:
|
you may thus also want to rethink the whole badge system to reward the points which actually is a better metric for contributed effort. If you need 24 hours to complete a task, that's your contributed effort. And so it follows that time is your contributed effort. Points or credits are the reward you get for your contribution, they aren't a contributed effort, they are the result of your contribution. If you wouldn't get points and you wouldn't get badges for runtime, you wouldn't be awarded anything. Suppose you wouldn't get points, then you would still get badges based on runtime. Now, the situation is that you get points AND badges for your contribution. They are two different things. You can't express contributed effort in points. They are two different things. No, the effort is in the points because it requires you to have the hardware and power requirements for it, you can gain 'time' by running on low spec hardware, my measly raspberry pi contributes lots of time but few WU's and points compared to a high end system, if I wanted to game the time based reward system I could do that easily by spinning up a lot of VM's and oversubscribe the underlying hardware, if you continue to challenge my point I may actually do this. |
||
|
|
Falconet
Master Cruncher Portugal Joined: Mar 9, 2009 Post Count: 3315 Status: Offline Project Badges:
|
SCC uses AutoDock Vina, not AutoDock 4.
----------------------------------------But I guess if they did use the GPU version of AutoDock for future targets, based on how long past work lasted using CPU's, I'm thinking we would have only a few days of work, assuming no restrictions on workunit release. ![]() - AMD Ryzen 5 1600AF 6C/12T 3.2 GHz - 85W - AMD Ryzen 5 2500U 4C/8T 2.0 GHz - 28W - AMD Ryzen 7 7730U 8C/16T 3.0 GHz |
||
|
|
|