| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: BOINC Agent Support
Thread: Task queueing when you know ahead of time a lack of net connection |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 39
|
|
| Author |
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges: 
|
Is there somewhere else to implement or invoke that option besides choosing Activity->Network Activity Suspended on the File/View/Tools menu from Advanced View? i.e. I don't find access to that option anywhere in Simple View. Thanks. Hmm, no, the option isn't present in Simple View, you'll need to switch to Advanced view to get the option to Suspend network.  "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges:
|
Nice try! Since you asked: <on_frac>0.997695</on_frac> <active_frac>0.999859</active_frac> <cpu_efficiency>0.988450</cpu_efficiency> <duration_correction_factor>1.733994</duration_correction_factor> I am a WCG-only person, so no other external project involved, and all my devices are usually running a single WCG project at a time, precisely to avoid the scheduler (of the client) to be too much distressed. The parameters is completely normal, and since single-project there isn't any reasons to run "High priority" with the current work... Now, enabling <rr_simulation> and possibly <cpu_sched_debug> (both in <log_flags>-part of cc_config.xml) will maybe reveal any wrong-calculations made by the BOINC-client. But, since you're clearly running an older client, if you can't replicate the behaviour with a current v6.6.xx-client, it's doubtful either flag will give any usable info to help improve BOINC-client. "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
JmBoullier
Former Community Advisor Normandy - France Joined: Jan 26, 2007 Post Count: 3716 Status: Offline Project Badges: 
|
if you can't replicate the behaviour with a current v6.6.xx-client, it's doubtful either flag will give any usable info to help improve BOINC-client. You will not lure me with such a thick line, Ingleside!  Why would I install a 6.6.xxxx version simply to see if I can replicate a strange behavior (not even a real blocking problem) which I have seen in all versions I have used since 5.10.45 (at least) and which I think Sekerob has already reported as still present in one or more of the many 6.6 versions he has already tested. Despite what you say in every other post of yours 6.2.28 is not full of bugs, and by the way I don't know how you may say that since you have also said that you have never been able to install it in your machines? Please stop trying to push anybody reporting a problem in these fora to install a version that we do not support. Thank you for understanding. Jean. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Barney does not say what client, but there are many reports of a seriously confused 6.6.36 scheduler. Well, I can attest to that. The above client is 6.6.36/quad. Sekerob, I'm running the 6.2.28 client, and after my monkeying around with all the various settings; the client misbehaved worse than a child on crack! I think my 6.2.28 version had a Charles Manson moment. As I indicated, I actually had to uninstall the client and reinstall it to get back to my actual preferred configuration where there's no pending WU's until about 7 - 15 minutes before one of the WU's that is in progress is about to complete. That is all. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
So, all we need is a scheduler that works as expected. Not much to ask for, right? Schedulers are childs play to create; as long as the expected behavior can be formulated with succinct and explicit rules that do not deviate from the pattern. From my experience, in most cases; the creation of the an initial scheduler generally works as was intended. Only after new and enhanced "Features" are introduced to make the scheduler "BETTER" without understanding all the other ramifications to the entire system do schedulers become a hodgepodge where it no longer performs the actions as initially intended. Introducing queuing and selection priorities that were never intended cause lots of unforeseen let alone anticipated almost unexplainable odd behaviors. My comments are not intended as criticism, just observations from past experience with creating schedulers. Been there, done that, all to many times. |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
et al
----------------------------------------1. <cpu_efficiency>0.988450</cpu_efficiency> parm does not seem to exist in either my 6.2.28 and 6.6.36 (test) client. Can see it in the client_state.xml of the 5.10.45 client. Guess it was deprecated, though I liked it. 2. Tested with some connect times and various combinations that make buffered work with deadlines to be further out than the next and consequent scheduled contacts will cause a High Priority condition. E.g. 4 days CAE, 1 day ABW. Some work has a deadline of 5 days. The client figures that okay, next up, connect in 4 days, but the next one after is 8, so panic state occurs. By playing these settings was able at will to change work from HP to normal processing state and back. Message being, if you buffer in the extreme 10 days and the connect is out 10 or longer AND the regular 10 day deadline, also with the 24 hour BOINC safety in mind, will cause an HP state. DID NOT stop work fetch though, when manually setting the network connected to always. There must be a reason for that.
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges:
|
et al 1. <cpu_efficiency>0.988450</cpu_efficiency> parm does not seem to exist in either my 6.2.28 and 6.6.36 (test) client. Can see it in the client_state.xml of the 5.10.45 client. Guess it was deprecated, though I liked it. It was removed in either v6.5.xx or v6.6.xx, so it should be present in v6.2.28. But, possibly you'll not let the client run long enough since last used v6.6.36 for <cpu_efficiency> being present... Message being, if you buffer in the extreme 10 days and the connect is out 10 or longer AND the regular 10 day deadline, also with the 24 hour BOINC safety in mind, will cause an HP state. DID NOT stop work fetch though, when manually setting the network connected to always. There must be a reason for that. The 24-hour "safety-margin" was removed in v5.10.xx, but the 10% "safety" for mis-estimation is still present, alongside "Connect..." and "Switch between applications every N minutes". Meaning, with a very low "Connect...", a task in a high-resource-share-project that has example one hour estimated left to run can stay paused upto maybe 2.5 hours before it's deadline before it switches to "High Priority". As for continuing to fill-up upto "Connect..." even if runs "High priority", not sure, but would guess this is to try if project has any work with longer deadlines that can fit within cache. Now, if all work has the exact same deadline this won't work, but some projects does have variable work... "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Who knows... I've got 5 test clients on this machine which I can flip at will, all pointing to the same data set. I've not understood the missed opportunity to put all these parms into the properties screen of the project when using the BM... let's see, pre-test build of 6.6.38... No, not there, neither any of the network/performance fractions of the client. Maybe something for another overall properties screen ;>)
----------------------------------------WCG's 'Normal' deadline, which is the only thing run presently, is 10 days. The cache level is set to it wont receive rush work. Of course as work is fetched on the go, what's In-Cache has varying deadlines.
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
JmBoullier
Former Community Advisor Normandy - France Joined: Jan 26, 2007 Post Count: 3716 Status: Offline Project Badges:
|
1. <cpu_efficiency>0.988450</cpu_efficiency> parm does not seem to exist in either my 6.2.28 and 6.6.36 (test) client. Can see it in the client_state.xml of the 5.10.45 client. Guess it was deprecated, though I liked it. Not only does it exist (in 6.2.28 and in 6.2.18 in my case), but it is used, it has not been simply left behind after an update. The one I have shown for my P4HT (6.2.28) is showing a different value right now. For the rest of this discussion I am not concerned at all with these extreme settings so I let you sort it between both of you if you like. Cheers. Jean. |
||
|
|
|