| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: Website Support
Thread: New Status in Column? |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 18
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
When one looks at this page for an explanation of the various meanings on a page for results statsus
----------------------------------------http://www.worldcommunitygrid.org/forums/wcg/viewthread?thread=17303 It strikes me that a status is missing. Can we get a status "RUNNING" be introduced which would have a completely different meaning than "In Progress". As I read it, "In Progress" means the WU's been dispatched to a system for computational analysis. It does not mean the WU is actually being worked on. So when you look at the detailed report for a particular WU such as this:  What one can gleem is that there is a result still outstanding, but you don't know 1) if it's running; nor 2). where it is in the queue depth. It seems like introducing a "RUNNING" argument would be easy enough to do (but it's always a simple matter of programming... I know.) Basically, I would think that when a WU was selected by the client for processing; all it would need to do would be to queue a small msg to be sent back, indicating that the task had started to run. Since WCG maintains a computational model of each machine, it could predict the estimated time the WU should be returned. Updating this page with that kind of information might be beneficial to those who are currious about if / when the WU will be validated. As I understand it, if WCG has "EMERGENCY" re-work or data that needs to be returned within 'N" units of time, WCG selects those machines that are "proven" to process and return the WU quickly. So that information seems to already be available. It seems WCG can "predict" when a machine would be likely to provide the data back. As I said, this should be a simple task, but what do I know? Yeah, Yeah, Yeah, I know this would require some coordination between getting the client / WCG web-page / WCG Scheduler to do something together.. it's called cooperation  Wadaya think?  [Edit 1 times, last edit by Former Member at Jul 27, 2008 5:43:49 PM] |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
No, don't think so. That would exponentially increase the amount of client server communications and force too many updates probably causing it to grind to a halt.
----------------------------------------
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello BarneyBadass,
"In Progress" is all the server knows. It means "Dispatched but not returned". Only the client knows whether or not it is 'Running". Use Boinc Manager or BOINCView to see whether a work unit is actually running. Lawrence |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Sekerob,
----------------------------------------I suspect it's more linear than exponential... but it's not my system so I haven't a clue how this is put together. Lawerence. Your absolutely correct. Only the client knows for sure (oh does that date me or what?) Hence; why I indicated that when the client actually selected the WU for analysis a small msg could be returned indicating its state change. BTW... there is an additional benefit to doing implementing this... In the example above, it indicates that a WU is still pending to be returned. As it stands the outstanding WU has a DUE time of 8/3 at 08:02:18. Let's presume it will take this machine 8 hrs to run this WU and it gets selected for processing on 8/3 at 01:00. Since WCG knows this is the case and it's outside the boundry of when it will be returned (in this case by only a couple of hours) then the decision about if I need to re-queue the WU to a faster machine can be made before the WU is even returned. I don't know, this seems like a win-win for everyone involved.. but it's not my call. [Edit 2 times, last edit by Former Member at Jul 27, 2008 6:05:11 PM] |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Sekerob, I suspect it's more linear than exponential... but it's not my system so I haven't a clue how this is put together. Lawerence. Your absolutely correct. Only the client knows for sure (oh does that date me or what?) Hence; why I indicated that when the client actually selected the WU for analysis a small msg could be returned indicating its state change. Question is, how often does the client tell the servers that a job is running? On a multiproject client with a scheduled project switch default of 60 or 120 minutes, it would indicate running on the server, when it may be in "waiting to run" on the client. So, I figure the amount of comms will be at least double but think it could be substantially more. Now i noticed your original post was expanded. My answer may have been more elaborate, but not going to as the point is made. Not likely to happen. The Mentioned BOINCview is the choice tool to monitor progress of all clients on a LAN simultaneously.
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hi BarneyBadass,
We call ourselves a grid, but really we are only a loosely coupled computer cluster, using dialup to occasionally connect the laptops with the servers. For that matter, keeping the servers from being overloaded is a BOINC priority, since we are not making money with BOINC. Most BOINC server farms are minimal. The infamous "Ready to Report" condition is an example of how BOINC works hard to refrain from overloading the servers. You can ask for this change ( you have already ) but I do not expect it this decade.Lawrence |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Guy's
Thanks, I appreciate your comments... in an effort to always have this system available for new higher priority WU's Here's how I've set up my Bionic network kind of parms:  I'm just hoping the client is smart enough to not consume my network (which I've not seen yet anyway) with frivolous network giberish. What my parms attempt to do is basically say is this: When a WU gets within about 8 minutes of competition; request a new WU; and report it back as being complete within about 8 seconds. I'm hoping this kind of responding can indicate it's a reliable system. Of course, not knowing how the bionic code is put together; it could actually take cycles away from the computational effort for a WU. (although I've not seen that effect much either yet). So I'm hoping the Bionic Client has a set of timer pops that get set when the WU's start up indicating about when to start looking for new WU's. I can hope, but not having the code so I really know doesn't leave me anything but being in the dark and having to use the good ol'l trial n' error method of discovery. Nor, is there a book or anything else that I've been able to find (yet) that describes the consequences the Bionic client experiences because of my parm settings. |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
The value "connect about every" is legally also 0.0000 which tells the client to just seek contact as and when it needs to upload work, with your additional buffer / cache driving it to at least ask for something 8 minutes before. Never tried it myself.
----------------------------------------Someone reported a problem with 0.0000 but afterwards he could not replicate it.
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
So far, my parms have not introduced anything that present any detrimental affects on the client.
I've sat and watched the thread switches and see nothing thats really causing any pain... but not knowing all the intricacies and nuances of the code doesn't mean I'm not missing something. BTW.. I didn't reply to your "how often should the client reply"... once.. at the selection of the WU for computational modeling. All the other states would be handled through normal task termination processing as it appears to be done today. I apologize for not answering that question before. |
||
|
|
JmBoullier
Former Community Advisor Normandy - France Joined: Jan 26, 2007 Post Count: 3715 Status: Offline Project Badges: 
|
BTW.. I didn't reply to your "how often should the client reply"... once.. at the selection of the WU for computational modeling. Plus once when a high priority job starts and makes this task "Waiting to run", plus once when another completing task allows this waiting task to resume, plus once when you decide to suspend one task, and once when you resume it, plus when you decide to suspend network activity (but how will it do it?) plus when you switch to another Grid or when you snooze your PC or when you stop it completely or when you leave for vacation, or..... Are you getting the picture better? The current way of doing is not precise enough for the few like you (and me sometimes) who keep a close look at what happens in their machines. But for the vast majority it is all fine and the most efficient from a resources viewpoint. Cheers. Jean. |
||
|
|
|