I run Seti and Einstein (and Orbit, haha) on three machines, one of which is a fairly good cruncher on which I recently installed Lunatics. Two have Boinc 6.10.60, the other has .58. Is there a good reason for me to upgrade?

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

I run Seti and Einstein (and Orbit, haha) on three machines, one of which is a fairly good cruncher on which I recently installed Lunatics. Two have Boinc 6.10.60, the other has .58. Is there a good reason for me to upgrade?

The claim is, that the scheduler has been improved for those doing multiple projects, and apparently panic mode has been returned back to the original design EDF mode.

I run Seti and Einstein (and Orbit, haha) on three machines, one of which is a fairly good cruncher on which I recently installed Lunatics. Two have Boinc 6.10.60, the other has .58. Is there a good reason for me to upgrade?

The claim is, that the scheduler has been improved for those doing multiple projects, and apparently panic mode has been returned back to the original design EDF mode.

I suspect that the "improved" scheduler may be in the eye of the beholder.

Everybody has their own personal view of what they want to happen when they devote a "resource share" to multiple projects. And they also have an idea of what they expect to happen - which may or may not be the same.

In some cases, I'm finding that the new 'fair share' concepts lead to outcomes that I'm having difficulty describing as 'better', though I can see the theory behind the change. So, I expect that - as with all change - some people will like the new way, and others will want to go back to what they were confortable with. Time will tell how many are in each camp.

I run Seti and Einstein (and Orbit, haha) on three machines, one of which is a fairly good cruncher on which I recently installed Lunatics. Two have Boinc 6.10.60, the other has .58. Is there a good reason for me to upgrade?

The claim is, that the scheduler has been improved for those doing multiple projects, and apparently panic mode has been returned back to the original design EDF mode.

I suspect that the "improved" scheduler may be in the eye of the beholder.

Everybody has their own personal view of what they want to happen when they devote a "resource share" to multiple projects. And they also have an idea of what they expect to happen - which may or may not be the same.

In some cases, I'm finding that the new 'fair share' concepts lead to outcomes that I'm having difficulty describing as 'better', though I can see the theory behind the change. So, I expect that - as with all change - some people will like the new way, and others will want to go back to what they were confortable with. Time will tell how many are in each camp.

Sounds like I might as well sit tight until someone convinces me this change will be good for me.

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

Sounds like I might as well sit tight until someone convinces me this change will be good for me.

I'd make the change immediately if I thought it would be a help to the project. But I already do the equivalent of work fetch hysteresis by only letting BOINC use some of my dial-up bandwidth once or twice a day. And REC only matters for multiple projects, but I concentrate on either S@H or SETI Beta and am really only doing both for a day or so when my focus shifts.

Eventually 7.0 will stop using DCF (when the server code is rebuilt and sends <dont_use_dcf\>) and I basically agree with Dr. Anderson that it conflicted with the server-side scaling to control runtime estimates. That may eventually help the project, but I patched the 6.10.58 I'm using with what amounts to <dont_adjust_dcf\> last year. That serves the same purpose, but also allows me to manually compensate for an inaccurate APR so the right amount of work is requested.

                                                                   Joe

If the project backoffs were the same as for v6.10.xx i'd probably give it a go, but if they're anything like those for v6.12.xx i'll stay well away.
With network bandwidth almost permanently maxed out, even with continuous manual Update button clicking v6.12.xx is a great way to run out of work.

---

Grant
Darwin NT

Eventually 7.0 will stop using DCF (when the server code is rebuilt and sends <dont_use_dcf\>) and I basically agree with Dr. Anderson that it conflicted with the server-side scaling to control runtime estimates. That may eventually help the project, but I patched the 6.10.58 I'm using with what amounts to <dont_adjust_dcf\> last year. That serves the same purpose, but also allows me to manually compensate for an inaccurate APR so the right amount of work is requested.

On what date is this likely to happen please? With the mix of GPU speeds I have it's impossible to get the DCF stable on this system. I would be happy with <dont_adjust_dcf\> being set TRUE from Tuesday 17-Apr-2012. Other then recompiling BOINC is there any way I can set it now?

14/04/2012 01:09:06 | SETI@home | [dcf] DCF: 0.932832->4.935688, raw_ratio 4.935688, adj_ratio 5.291078

I switched from 6.12.34 to 7.0.25 on this system a few days ago and have had no real problems getting enough WUs with either version since I added SETI@home Auto Retry to SIV. The system has a RAC of about 50,000 and needs an average of about 700 WUs per day. At the moment both my systems are hitting the <censored> 400 + 50 limits.

[GPU CUDA Information] <- SIV64X - System Information Viewer V4.28 Beta-31 RED::ray

                nVidia CUDA V4.10    Peak  Compute
|Bus-Numb-Fun|  Device Name        GFLOPS  Capability

[ 3 - 00 - 0 ]  GeForce GTX 460    1025.5  V2.01
[ 4 - 00 - 0 ]  GeForce GTX 460    1025.5  V2.01
[ 5 - 00 - 0 ]  GeForce GT 430      268.8  V2.01
[ 7 - 00 - 0 ]  GeForce GT 520      155.5  V2.01

I switched from 6.12.34 to 7.0.25 on this system a few days ago and have had no real problems getting enough WUs with either version since I added SETI@home Auto Retry to SIV.

There's the catch. You need another programme just to get work to keep the system busy.
It shouldn't be necessary.

---

Grant
Darwin NT

I switched from 6.12.34 to 7.0.25 on this system a few days ago and have had no real problems getting enough WUs with either version since I added SETI@home Auto Retry to SIV.

There's the catch. You need another programme just to get work to keep the system busy.
It shouldn't be necessary.

Quite correct. My hope was by adding this to SIV DA would see how pointless the huge backoffs are and remove them.

Eventually 7.0 will stop using DCF (when the server code is rebuilt and sends <dont_use_dcf\>)...

On what date is this likely to happen please?
...

I can't guess. I had thought it might happen as soon as last Tuesday when they adjusted the ET_RATIO_LIMIT.

If the servers' code were fully rebuilt from either BOINC's "Server stable" branch or trunk now, a sched_reply would say <scheduler_version>701</scheduler_version> rather than the 613 we now see, but only a build from trunk would follow that with <dont_use_dcf\>. Sometimes we get new features very soon after they're added to the code base, but not always.

                                                                   Joe

I run Seti and Einstein (and Orbit, haha) on three machines, one of which is a fairly good cruncher on which I recently installed Lunatics. Two have Boinc 6.10.60, the other has .58. Is there a good reason for me to upgrade?

Absolutely nothing that I can see that would make me even think about going and downloading it but then again I felt the same about the 6.12.xx versions as well.

My moto is, "if it ain't broke then don't screw with it". ;)

Cheers.

---

Eventually 7.0 will stop using DCF (when the server code is rebuilt and sends <dont_use_dcf\>)...

On what date is this likely to happen please?
...

I can't guess. I had thought it might happen as soon as last Tuesday when they adjusted the ET_RATIO_LIMIT.

Thank you I will keep my fingers crossed.

Is the plan to remove the 400 + 50 limits for BOINC V7 and later but leave them there for V6 and earlier?

Ray, those limits are set server side not client side, so are all but independent of client version.


(I say "all but" because some old client versions don't send the right data back to the servers so can collect huge caches that they are unable to complete within the WU deadlines....)

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Ray, those limits are set server side not client side, so are all but independent of client version.

(I say "all but" because some old client versions don't send the right data back to the servers so can collect huge caches that they are unable to complete within the WU deadlines....)

Rob, I know all too well the limits are set server side but the server could easily have different limits for different client versions.
I feel that old client versions don't send the right data should have limits of 0 + 0.

I can understand the blocking of older clients to a "1 in 1 out" approach, which would certainly help reduce their bloated caches.

But why the desire to restrict the newer (6.x.y) clients which form a large part of the client base? One of the problems just now isn't the size of cache, but the re-supply logic that is obviously "not correct", I've done some work for a company that specialises in providing fairly robust internet connections over restricted bandwidths and the last thing you want are stupid long retry/back-off delays, coupled with very short, and very long "go to re-"try delays this causes massive customer frustration, increases server workload, and reduces effective bandwidth by virtue of the increased connection management traffic that flies around.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

But why the desire to restrict the newer (6.x.y) clients which form a large part of the client base? One of the problems just now isn't the size of cache, but the re-supply logic that is obviously "not correct", I've done some work for a company that specialises in providing fairly robust internet connections over restricted bandwidths and the last thing you want are stupid long retry/back-off delays, coupled with very short, and very long "go to re-"try delays this causes massive customer frustration, increases server workload, and reduces effective bandwidth by virtue of the increased connection management traffic that flies around.

I simply asked if this was the intent. If the project wishes to get users to migrate to V7 then removing the 400 + 50 limits for V7 only would be one way to make this happen. Given this thread is why should I switch to 7.0.x should this be the plan it would be a good reason to switch.

I feel you should start a new thread on now re-supply should work. I would like to be able to ask once a day, return 700 results and get the 700 WUs I need all at once. Having the system do the following every 5 minutes is a total waste of bandwidth.

14/04/2012 09:25:30 | SETI@home | Sending scheduler request: To report completed tasks.
14/04/2012 09:25:30 | SETI@home | Reporting 1 completed tasks, requesting new tasks for CPU
14/04/2012 09:25:37 | SETI@home | Scheduler request completed: got 0 new tasks
14/04/2012 09:25:37 | SETI@home | No tasks sent
14/04/2012 09:25:37 | SETI@home | This computer has reached a limit on tasks in progress

AFAIK the projects have only rarely insisted on versions higher than ver x. They are more interested in processing and returning their tasks.

Seti is quite often has the first servers to update code, but that is obvious because Dr.A is in the same location.

I usually only upgrade, if my computers require it, like when GPU crunching becaame a reality, that required a BOINC upgrade.

And often the "improvements" in BOINC in reality are not.

If you red my first post here, I did say "the claim is ..." I did not say it is an improved scheduler. And Richard has said that "Panic Mode" has reverted to JM7's original design for EDF, which implies again upgrades are not necessarily improvements. (quite often true in all walks of life)

The most significant changes in BOINC v7.0.x - the only ones which could justify any project setting a minimum BOINC client level - are the support for new technologies.

These are things like:

• the virtual machines used by CERN's Test4Theory project
  
• true OpenCL scheduling, as being tested by Einstein's 'Albert' test project
  
• future 'distributed storage' projects (none even in test mode yet)
  

I doubt that any of those will be sufficient to make SETI set a minimum client for many years to come, although the OpenCL support may become desirable for some members here as that technology matures.

Until then, I refuse to upgrade, and I will also continue to refuse participating in FACEBOOK, and TWITTER. :-)

A man after my own heart:-)
Never seen the need for that lot either.

But I took a chance and upgraded to v7.0.25... with the usual chaotic results:-)

Cheers,

---

Cliff,
Been there, Done that, Still no damm T shirt!

WinterKnight wrote:

and apparently panic mode has been returned back to the original design EDF mode.

I've been having annoying trouble with a host running CPU Einstein GW and GPU Einstein BRP. About a week ago I got into a state in which Boinc thought I could be in deadline trouble on the CPU work--and as is the pattern on boincmgr 6.12.34 (and many others) made counterproductive choices of next work to run. I quelled these by suspending most of the CPU work in my queue save the nearest day or two, and kept testing to see if the High Priority state would cancel. As of today, the nearest CPU job deadline was seven days away, but with well under seven days of CPU work in the queue, still HP was declared.

You'll guess I looked forward to resumed EDF scheduling under HP, and indeed I did, but I was even happier that on resuming computation after installing 7.0.25 on this host over 6.12.34 it thought the better of the High Priority need.

I've stumbled over what I regard as toxic behavior in this area enough in the last year or so that the hope for improvement (for my particular case and liking) in this area alone is sufficient reason to make the change. Others will have other priorities.

---