Welcome to MilkyWay@home

request regarding "deferred communication" times

Message boards : Number crunching : request regarding "deferred communication" times
Message board moderation

To post messages, you must log in.

Previous · 1 · 2

AuthorMessage
Sunny129
Avatar

Send message
Joined: 25 Jan 11
Posts: 271
Credit: 346,072,284
RAC: 0
Message 52150 - Posted: 1 Jan 2012, 2:17:26 UTC

b/c even if some consider that an alternative, there's still no excuse why scheduled tasks concerning BOINC commmand line calls shouldn't work, and it doesn't fix the actual problem i'm having with scheduled tasks...
ID: 52150 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile mikey
Avatar

Send message
Joined: 8 May 09
Posts: 3315
Credit: 519,757,209
RAC: 27,872
Message 52151 - Posted: 1 Jan 2012, 12:36:37 UTC - in response to Message 52150.  
Last modified: 1 Jan 2012, 12:41:09 UTC

b/c even if some consider that an alternative, there's still no excuse why scheduled tasks concerning BOINC commmand line calls shouldn't work, and it doesn't fix the actual problem i'm having with scheduled tasks...


I am thinking there is a time out on the Server side too, where if a User bangs on the door trying to get in earlier than it thinks they should it gives longer and longer time outs for that User, man it has been a LONG time since I thought about stuff like this! We used to talk about this stuff A LONG TIME AGO when I was a Forum Admin over at Seti and they were having MAJOR problems. You can test this manually by doing a manual update and then trying again before the timeout end, if your next timeout is longer it is Server sided. If not try again, and again, and again and I think you will see the timeout time grow longer and longer. Now as to why the script isn't working to even try to connect...I have no clue, sorry.
ID: 52151 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Sunny129
Avatar

Send message
Joined: 25 Jan 11
Posts: 271
Credit: 346,072,284
RAC: 0
Message 52162 - Posted: 1 Jan 2012, 18:41:07 UTC

You can test this manually by doing a manual update and then trying again before the timeout end, if your next timeout is longer it is Server sided. If not try again, and again, and again and I think you will see the timeout time grow longer and longer.

yeah, i've never noticed that myself as far as scheduler requests are concerned. but maybe that's b/c i never try to update a project/contact its server before the default back-off timer elapses. i learned a long time ago that doing so will only result in one of those "request too soon: xx seconds" messages and restart the default back-off timer again. beyond that, i've never continued trying to update to see what happens, so i can't confirm that my back-off times would eventually increase, nor do i want to test that idea LOL...

that being said, even if it does work that way for scheduler requests, i've always had my scheduled tasks (or at least the ones that update BOINC projects) set to run at intervals that exceed the length their respective projects' default back-off timers. for instance, SETI@Home's default back-off timer is set to 5 minutes, so i have the scheduled task that's supposed to update SETI@Home set to execute every 6 minutes...that way it almost never gets a "request too soon: xx seconds" message. i say almost b/c occasionally BOINC will update SETI@Home on its own and then my scheduled task will execute less than 5 minutes later, resulting in a "request too soon: xx seconds" message. but from there the 6 minute intervals start over, and the BOINC automatic update doesn't happen again for hours or longer.

at any rate, i've been giving some thought to what you initially said about the BOINC software gurus possibly trying to come up with ways to prevent such methods. i wonder if the programmers/developers have the ability to construct the software such that it can detect how a given host's scheduler request was issued (i.e. distinguish between a scheduler request issued by the click of the mouse or a button on the keyboard versus one issued by a Windows scheduled task). even if they did though, i don't think that could be the reason this problem seemed to crop up all of the sudden, and on more than one host now (one of which is a fresh WinXP install) no less! i would think they would ultimately have to incorporate such a "fix" into the next BOINC software revision and hope that everyone (or at least a majority of users) will migrate...unless they're able to implement these kinds of changes in the client software over the internet through BOINC networks specifically...i don't know.
ID: 52162 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Profile mikey
Avatar

Send message
Joined: 8 May 09
Posts: 3315
Credit: 519,757,209
RAC: 27,872
Message 52176 - Posted: 2 Jan 2012, 13:17:52 UTC - in response to Message 52162.  

You can test this manually by doing a manual update and then trying again before the timeout end, if your next timeout is longer it is Server sided. If not try again, and again, and again and I think you will see the timeout time grow longer and longer.

yeah, i've never noticed that myself as far as scheduler requests are concerned. but maybe that's b/c i never try to update a project/contact its server before the default back-off timer elapses. i learned a long time ago that doing so will only result in one of those "request too soon: xx seconds" messages and restart the default back-off timer again. beyond that, i've never continued trying to update to see what happens, so i can't confirm that my back-off times would eventually increase, nor do i want to test that idea LOL...

that being said, even if it does work that way for scheduler requests, i've always had my scheduled tasks (or at least the ones that update BOINC projects) set to run at intervals that exceed the length their respective projects' default back-off timers. for instance, SETI@Home's default back-off timer is set to 5 minutes, so i have the scheduled task that's supposed to update SETI@Home set to execute every 6 minutes...that way it almost never gets a "request too soon: xx seconds" message. i say almost b/c occasionally BOINC will update SETI@Home on its own and then my scheduled task will execute less than 5 minutes later, resulting in a "request too soon: xx seconds" message. but from there the 6 minute intervals start over, and the BOINC automatic update doesn't happen again for hours or longer.

at any rate, i've been giving some thought to what you initially said about the BOINC software gurus possibly trying to come up with ways to prevent such methods. i wonder if the programmers/developers have the ability to construct the software such that it can detect how a given host's scheduler request was issued (i.e. distinguish between a scheduler request issued by the click of the mouse or a button on the keyboard versus one issued by a Windows scheduled task). even if they did though, i don't think that could be the reason this problem seemed to crop up all of the sudden, and on more than one host now (one of which is a fresh WinXP install) no less! i would think they would ultimately have to incorporate such a "fix" into the next BOINC software revision and hope that everyone (or at least a majority of users) will migrate...unless they're able to implement these kinds of changes in the client software over the internet through BOINC networks specifically...i don't know.


I do not THINK they can tell HOW the request was issued, just that you are trying to connect. One thing you could do to slow down your requests is to do a script that detects if Boinc is crunching, then if it is not issue the connect command and if it is crunching, then no connection is needed. I mean if you have Seti work why connect to ask for more? And if you don't have work then yes it does need to connect, right? I am not a script guy but since Boinc uses ALOT of cpu when it crunches you should be able to see that with a script. A simple app_info file, withing Boinc, will send units back as soon as they are finished if that is all you are after, but that isn't how this thread started.
ID: 52176 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Sunny129
Avatar

Send message
Joined: 25 Jan 11
Posts: 271
Credit: 346,072,284
RAC: 0
Message 52180 - Posted: 2 Jan 2012, 16:29:23 UTC - in response to Message 52176.  

I do not THINK they can tell HOW the request was issued, just that you are trying to connect. One thing you could do to slow down your requests is to do a script that detects if Boinc is crunching, then if it is not issue the connect command and if it is crunching, then no connection is needed.

well again, i really don't think the problem is that i'm trying to connect too often. remember, the only way i could even do that would be to either manually update the project too often using the update button in the BOINC manager, or manually run my BOINC-related scripts too often, neither of which i've done. it just doesn't make sense that the scripts execute just fine when i physically double-click them, but don't execute at all when instructed to by a Windows scheduled task. i guess what i'm saying is that, at the very least Windows should be able to actually run these scripts for me, even if it results in a project back-off or a denial of new work...and at the very least the result of such an attempted scheduler request should be in the form of a diagnostic message in the BOINC event log, which i don't get, and that's how i know that Windows isn't executing my scripts.


I mean if you have Seti work why connect to ask for more?

well i have slightly different reasons for using a script w/ SETI@Home than i do w/ MW@H. w/ SETI@Home, i'm not worried so much about project back-off times that far exceed the length of the short outages that induce them. rather i'm concerned with the amount of work in my queue. i typically only crunch SETI@Home Astropulse, and strictly on my HD 5870 GPU. if you're familiar with the SETI@Home project, then you know that the production of Astropulse tasks is few and far between. so its hard to get AP work to begin with, and i like to pad the cache as much as possible when i can so that i can be less concerned with whether or not there will be new AP work available when my cache starts to run low. the problem w/ AP is that (and i have no idea what the exact statistics would be, but...) hosts probably have a 1 in 100 chance of getting AP work per scheduler request, and even with my cache size set quite high, those scheduler requests only come once every few hours if that. so the best way to get new AP work when the AP splitter occasionally spits some out would be to use psychic powers and update the project at the exact moment that small amount of new AP work becomes available...and since i'm not psychic, my next best bet is to use a script that updates the project, and use a Win
ID: 52180 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Sunny129
Avatar

Send message
Joined: 25 Jan 11
Posts: 271
Credit: 346,072,284
RAC: 0
Message 52325 - Posted: 8 Jan 2012, 21:33:36 UTC

i was just coming to update the thread when i realized that a bit of my last post got cut off before posting. the end of that last sentence should read "...and use a Windows scheduled task to control when and how often the batch file executes."


...at any rate, this update is a good one. my Windows scheduled tasks seem to be working again on both hosts (one of which had just gotten a virus cleaned off of it, and the other which was a fresh installation of WinXP 32-bit). i believe the issue was in the naming of the batch files themselves. while i can't say that the names of my batch files were void of any and all special characters back before they stopped working altogether (they typically had underscores in them), they were void of the @ symbol. i know i've already said that i wasn't entirely sure when my scheduled tasks stopped working, but if they stopped working around the same time that i moved the HD 5870 GPU into the box that just had the virus cleaned off it, then the scheduled tasks also stopped working around the same time that i created a batch file for MW@H (named update_MW@H.bat) and renamed another batch file (from update_SETI.bat to update_S@H.bat). i have since renamed the batch files to update_MW.bat amd update_SETI.bat respectively and updated the scheduled tasks to point to the newly renamed batch files, and all is working again.

recall that i could execute the batch files by double-clicking them, even when they had @ symbols in their names, and that i could verify it by watching the DC project update in the BOINC event log. i think that maybe Windows scheduled task is unable to execute, or perhaps even recognize batch files with the @ character in their names for whatever reason(s). i'll probably never know for sure, as i'm reluctant to mess with anything to find out now that everything is working like it should...
ID: 52325 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Previous · 1 · 2

Message boards : Number crunching : request regarding "deferred communication" times

©2024 Astroinformatics Group