| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Active Research
Forum: Africa Rainfall Project
Thread: Work Available |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 3268
|
|
| Author |
|
|
Mike.Gibson
Ace Cruncher England Joined: Aug 23, 2007 Post Count: 12398 Status: Offline Project Badges: 
|
Thank you.
117 is a rapid advancement from Kevin's last post. If 182 is half-size, I would expect it to checkpoint every 25% instead of 12.5%, and the progress to advance in 0.042% stages instead of 0.021%. The increments correpond to 36 second intervals (1% of an hour). Mike |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
108 has become a priority in the last 2 hours. These are not resends
|
||
|
|
Mike.Gibson
Ace Cruncher England Joined: Aug 23, 2007 Post Count: 12398 Status: Offline Project Badges:
|
Thank you, entity. My spreadsheet has been updated.
|
||
|
|
Unixchick
Veteran Cruncher Joined: Apr 16, 2020 Post Count: 973 Status: Offline Project Badges: 
|
just got a 98 in the extreme group. 3 tasks sent.
ARP1_0001303_098_0 Darwin 18.7.0 In Progress 2021-12-02 10:14:54 UTC 2021-12-06 22:14:54 UTC ARP1_0001303_098_1 Darwin 21.1.0 In Progress 2021-12-02 10:13:22 UTC 2021-12-06 22:13:22 UTC ARP1_0001303_098_2 Darwin 21.1.0 In Progress 2021-12-02 10:15:14 UTC 2021-12-06 22:15:14 UTC |
||
|
|
Mike.Gibson
Ace Cruncher England Joined: Aug 23, 2007 Post Count: 12398 Status: Offline Project Badges:
|
Thank you, Unixchick. That's a big jump.
Mike |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
If 098 is an extreme laggard, that would make the current generation 121 (extreme being defined as -23 generations behind) and that should make 111 as a priority (priority being defined as 10 generations behind). 108 is the current priority generation so I'm probably not understanding how these different priorities are being defined or something has changed
|
||
|
|
Mike.Gibson
Ace Cruncher England Joined: Aug 23, 2007 Post Count: 12398 Status: Offline Project Badges:
|
entity
----------------------------------------My thoughts are that the procedures were intended so that the laggards would catch up. As we do catch up, I would expect the extreme definition to close up. It started as -25 so had already closed up by 2 and would seem to be continuing that trend. I suspect we might be up to a lead of 118 with the other definitions at -10 and -20. We will find out with Kevin's next report. Mike [Edit 1 times, last edit by Mike.Gibson at Dec 2, 2021 7:26:29 PM] |
||
|
|
alanb1951
Veteran Cruncher Joined: Jan 20, 2006 Post Count: 971 Status: Offline Project Badges: 
|
Unixchick's 3-at-once batch 108 task is interesting, isn't it...
I have received a batch 107 task and two batch 108 tasks that were created after that one (10:31 UTC and later...); none of them initially sent out 3 copies (though one of them now has a third copy because one of the first two was user aborted after 4 hours or so!) So from my viewpoint, these don't seem to be "extreme" yet... Mine are Linux-hosted, so I wonder if the three-at-once is something they're doing for Macs for one reason or another??? Cheers - Al. |
||
|
|
Mike.Gibson
Ace Cruncher England Joined: Aug 23, 2007 Post Count: 12398 Status: Offline Project Badges:
|
That is interesting. However, I would say that your use of the word created might be incorrect. That appears to be when the tasks were sent out rather than created. They would sit in a queue once they were actually created and then sent out later.
It is quite possible that the extreme laggards would jump the queue and so get out of sequence. Kevin has said that the criteria is established at creation. He has also said that the leading generation are held until there are 300 of them, so there is some queue jumping going on. Kevin's next report should clarify matters. Mike |
||
|
|
alanb1951
Veteran Cruncher Joined: Jan 20, 2006 Post Count: 971 Status: Offline Project Badges:
|
Mike,
That is interesting. However, I would say that your use of the word created might be incorrect. That appears to be when the tasks were sent out rather than created. They would sit in a queue once they were actually created and then sent out later. For what it may be worth, I used the word created because I was referring to the time listed at the top of the workunit information, not the information from the results page. For example, at the top of the information for workunit 66657271 are the following lines: Project name: Africa Rainfall Project My Sent time for this workunit was 2021-12-02 19:02:55 UTC and the wingman was 19:05:51 UTC. Now, if I look at typical OPN1 or MCM1 workunits there is typically a difference of over 24 hours between the workunit creation time and when the first copy gets sent out. For example, here's the top of the information for a typical OPN1 workunit: Project name: OpenPandemics - COVID 19 My Sent time for this workunit was 2021-12-03 05:07:09 UTC - no wingman [yet], of course :-) There is usually an excess of MCM1 and OPN1 work, whereas ARP1, OPNG and HST1 tasks are probably gone within minutes of being created/queued (if not held up deliberately), which results in the sent time being very close to the created time. Just thought I'd clarify my understanding (which could, of course, be wrong...) It all hinges on the definition of "created" for an ARP1 task after all - is it when it transitions, when it is queued or when it is actually released? (The first two may be the same...) Perhaps Kevin can clarify this?? Cheers - Al. |
||
|
|
|