another update:

ok, so i'm at work now, and i have remote control of my host at home via LogMeIn which, by the way, works like a charm just like someone mentioned it would (the only downside being slight network lag, which really isn't bad at all considering i'm controlling an entire computer over a network connection). at any rate, my host at home has been running 5 E@H CPU task and 2 MW@H GPU tasks concurrently for the last 2.5 hours without a single client disconnect!...and while i know 2.5 hours of stability means nothing in the grand scheme of things, it sure looks promising considering i was getting client disconnects every ~5 minutes w/ BOINC v6.10.60. if things continue without a hiccup over a 24 hour period i'll be happy.

---

Sunny, does boinc.exe disappear from task manager when the client apps stop? Also try 6.12.33 instead of 6.10.60. I've noticed that since 6.12.28 I'm getting far fewer client disconnection issues. We discussed this problem on the lists after 6.12.26...

good news guys...

after testing over a dozen possibilities over the last few days, i decided to resort to using a different version of BOINC. so i installed the latest developer version, v6.12.33, and haven't had a single failed connection all night long! i can confirm it b/c when i scrolled back to the beginning of the BOINC message log this morning, it showed 10:26pm, which is exactly when i restarted BOINC after installing the new version. it ran flawlessly like this all night while running 5 CPU tasks and 1 GPU task. i'm going to leave CPU tasks at 5 and increase GPU task to 2 at a time before i leave for work this morning, and see if BOPINC v6.12.33 remains stable and connected to the client all day until i get home.

Hey, I suggested 6.12.33 on the 17th. You could have saved yourself a weekend of pain :)
Glad it's fixed. What's a BOPINC (think I might have seen one hopping across the field this morning)?

Good news that one is cracked .... any closer to resolving the OP, remote connections or does it look like the local connection hassles were the root cause ?

Regards
Zy

Hey, I suggested 6.12.33 on the 17th. You could have saved yourself a weekend of pain :)
Glad it's fixed.

yes you did...i meant to thank you specifically for that, but as i was scrolling through the massive amounts of text in this thread to look for the reference, i couldn't find it. again, thank you. to be honest with you, trying a different version of BOINC was actually near the end of my list of things to do/try, simply b/c i had been using v2.12.26 prior to switching to v6.10.60, and that particular switch caused problems to crop up with S@H. in fact, as i mentioned above somewhere, i'm still not sure how v6.12.33 is going to play nice with S@H...i'm hoping that i don't get the same ridiculously large S@H project back-offs like i was getting w/ v6.12.26. i won't know that for a few days probably, as i'm going to stick with MW@H for a bit to ensure things continue to run smoothly...

Good news that one is cracked .... any closer to resolving the OP, remote connections or does it look like the local connection hassles were the root cause ?

Regards
Zy

well actually, the only reason my OP concerned remote connections is b/c i was trying to find a way to reconnect to the client without having to be sitting in front of that host. if you'll recall, BOINC would only reconnect to the client so many times successfully before the password error would pop up and prevent BOINC from reconnecting. someone would have to be there to do it manually, or else it would just sit there disconnected from the client with an idle CPU and GPU. but when i eliminated the client password per your suggestion, the password error went away, thus eliminating my need to control BOINC remotely and manually reconnect it to the client. sure, the failed connections still remained, but BOINC no longer had a problem reconnecting every time the connection would fail. it was at that point that the topic of the thread went from trying to control the BOINC client remotely to actually fixing the root of my "failed connection" problem (or more appropriately, my "random boinc.exe termination" problem).

b/c of this, i haven't really gone back and further researched the topic of the OP - controlling the BOINC client remotely. that being said, i am inclined to say that, yes - the local connection hassles were the root cause of my not being able to directly control BOINC remotely on anything other than a local network. as you can see above, i ended up having to resort to using LogMeIn in order to access the BOINC client on my host at home. but despite it giving me indirect control of BOINC (through direct control of the whole host computer), it did ultimately allow me to control the BOINC client on my host at home across non-local networks.

---

b/c of this, i haven't really gone back and further researched the topic of the OP - controlling the BOINC client remotely. that being said, i am inclined to say that, yes - the local connection hassles were the root cause of my not being able to directly control BOINC remotely on anything other than a local network. as you can see above, i ended up having to resort to using LogMeIn in order to access the BOINC client on my host at home. but despite it giving me indirect control of BOINC (through direct control of the whole host computer), it did ultimately allow me to control the BOINC client on my host at home across non-local networks.

Okie Doke - your LogMeIn solution will probably be a more equitable solution for your Workplace Network Admin in any case, it'd stop them having too many heart failures(!), nice workaround :)

Regards
Zy

perhaps the developers will improve BOINC's ability to be controlled remotely by making it easier to do so over non-local networks. even though i found a workaround with LogMeIn, i'll continue to toy with BOINC's own remote control functionality for the good of the community. it won't be a full-on research project or anything, but i won't completely forget about it either. Beyond asked me to posy details if i make any progress with it:

If you do figure out how to make BOINC Manager do remote connections reliably please post instructions.

...and so i'll continue to look into it over time.

---

to be honest with you, trying a different version of BOINC was actually near the end of my list of things to do/try, simply b/c i had been using v2.12.26 prior to switching to v6.10.60, and that particular switch caused problems to crop up with S@H. in fact, as i mentioned above somewhere, i'm still not sure how v6.12.33 is going to play nice with S@H...i'm hoping that i don't get the same ridiculously large S@H project back-offs like i was getting w/ v6.12.26. i won't know that for a few days probably, as i'm going to stick with MW@H for a bit to ensure things continue to run smoothly...

You're very welcome, I was just teasing you. Now what was that bird I saw hopping across the road? Seriously, SETI has had various strange problems since it's BOINC inception. Ars Technica was originally a team specifically formed to crunch SETI Classic and we climbed to #1 before the big nationalistic teams were formed, but since BOINC and the SETI BOINC version were created there has been problem after problem. Seems odd since the developers are closely tied. Most of us dropped the project except for an occasional foray to see if things have improved. Maybe some day... I'd leave things run for a while though as it often takes allocations days to normalize after changes in BOINC scheduling methods.