Hmm... some work has gone out the last hour - Results in progress jumped from 14k to 24k.
Gotta try and get some...

[edit]...to feed my credit hunger :)[/edit]

---

mic.

Validator, assimilator and deletor have a small backlog: 350, 150, 100. Could be why few wu's are going out. or this new batch is drying up.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

But the reason the WU's were improved by a factor of 60 was that the previous application turned out to be VERY inefficient. The optimized application produces the same science in 1/60 the time. So my thinking is to increase the amount of science in the newer work units, NOT to reduce the efficiency. If that is done, the amount of optimization available in another go round probably would be a LOT less. It isn't clear that the optimized application was developed primarily out of 'credit hunger', rather a sense of 'this is wasteful and I can fix it' seems to have been a motivation.

So the problem regarding getting work now can (in my view) only be addressed by producing work units that each do a LOT more science and thus run a lot longer (1 hour to 2 hours or perhaps even longer), while retaining the same volume of work units and the same cache limitations and scaling up the credit awards to reflect per work unit to remain in sync with the credit per CPU cycle which currently exists.

The 'credit hunger' comment does suggest an alternate approach (which might have some effect), of simply dropping the credit award for the current work units -- say by an additional factor of 2 to 4. That might possibly reduce the number of CPU cycles chasing Milkyway work units. (Heck, being honest, I'd respond by dropping back my resource share to MilkyWay -- currently it gets perhaps 60% of my farm CPU cycles, if the credit per CPU cycle dropped by a factor of 4, MilkyWay might only get 25% of my CPU cycles -- I'd still remain attached to it. With the lower 'need' rate all around for Milkyway, I'd find it less of a chore to keep workstations fed with workunits -- as right now, the manual effort is wasteful.

While I agree with most of what you have stated.

If I had stuck to stock appp the WU's on my Q6600 would have taken 7 hours 33 miniuts, and would have ment over running report dates.

Changing up a gear they then took 6 - 7 miniutes.

I to am now out of work.

But making the work units longer 4 hours would knowing human nature just get someone to design a new app that would reduce it down to 6 miniutes.

I have been running this type of project since seti started in 1999 and as WU get longer apps get faster,and host get OC.

IMHO The main motive behind this is credit hunger.

Michael

---

...
, while retaining the same volume of work units and the same cache limitations and scaling up the credit awards to reflect per work unit to remain in sync with the credit per CPU cycle which currently exists.
...

IMHO the goal must be to get in sync with other projects. It's just ridiculous how more and more M@H crunchers overrun anyone doing some other project in BOINCStats...

No need to go in sync with Seti or Einstein, but at least with the 2nd or 3rd best paying project.

---

mic.

... No need to go in sync with Seti or Einstein, but at least with the 2nd or 3rd best paying project.

Why not the 1st? *grin*

---

Lovely greetings, Cori

... No need to go in sync with Seti or Einstein, but at least with the 2nd or 3rd best paying project.

Why not the 1st? *grin*

Alternatively, why not start getting people to ignore BOINC-wide stats and standings and only focus on the individual project standings? Start getting people at the stat sites together to come up with a new BOINC-wide ranking system that has an exchange rate per project. Remove the entire credit debate from BOINC leadership (Anderson, et al.) and the projects.

I take your point, but goal for whom? As to payout rates, the SETI *optimized* clients pay out more than twice the regular clients. This includes the new Astropulse optimized client which requires a bit more expertise to deploy compared to other optimized clients. Seeing Milkyway drop down to say some number marginally above that of the freely available optimized clients for SETI probably is not unreasonable. That WOULD be a significant drop from where it is now -- but it might assuage the Dave Anderson is a deity crowd <smile>.

Then again, the current situation is sort of taking care of itself, with the very efficient optimized client, the lack of available work is dropping the RAC of many (most) folks here. Mine is already down some 15% and is continuing to drop, -- simply because of the lack of work. I've already dropped down my resource share here and am seeing other projects (SETI, Spinhenge, Climate, Rosetta and Malaria) increase RAC as a result. I suspect those who are multi-project are seeing something similar. It is possible that the only folks who might be maintaining their RAC here would be single project configurations which (I believe) puts a greater automatic pressure on looking for work. For multiproject configurations, when MilkyWay reports out of work, BOINC simply says 'thank you' and moves on, it won't come back to recheck automatically for some time cycle, as it has other projects to keep it happy enough. That's why I have needed to do some manually 'get me more work' runs for MilkyWay -- but that is not something I expect to continue to do -- just too time consuming and frustrating. So for me, absent a change at the project, I expect that I'll reduce my MilkyWay CPU cycles (and RAC) even with no change in the credit scheme by another 20% to 40%. Not a big deal, while the bodacious numbers Milkyway was generating for my farm has been neat, I tend to prefer to maintain something of a balance in my project total work rankings -- as you can see from my signature here.

IMHO the goal must be to get in sync with other projects. It's just ridiculous how more and more M@H crunchers overrun anyone doing some other project in BOINCStats...

No need to go in sync with Seti or Einstein, but at least with the 2nd or 3rd best paying project.

---

Alternatively, why not start getting people to ignore BOINC-wide stats and standings and only focus on the individual project standings?

That's ok when you run only one project, but not for multis.

Start getting people at the stat sites together to come up with a new BOINC-wide ranking system that has an exchange rate per project. Remove the entire credit debate from BOINC leadership (Anderson, et al.) and the projects.

Even better, well, it's effectively the same. But until they are done we still night need some cpp maintained by the projects.

---

mic.

I tend to prefer to maintain something of a balance in my project total work rankings -- as you can see from my signature here.

HUH! not to nitpick but your milkyway rac is almost 4 time as much as the rest put together how is that balanced

---

Not the RAC -- ranking based on total credits for each of the projects.

RAC will vary from time to time, after all, my MilkyWay RAC was 0 a year ago. I try to get to a 99.9 on each project (note that two of them are dead -- hard to balance RAC there, don't you think?).

HUH! not to nitpick but your milkyway rac is almost 4 time as much as the rest put together how is that balanced

---

My goal is to bury Seti at the bottom of my stats and I've accomplished it here in a couple of months what it took me well over a couple of years at seti. And that really is secondary to evening out my other projects in over all credits.

Goals - Einstein - 1 million
CPDN - 500,000
Milky Way - 500,000

Seti when I'm desperate.

I run Einstein on all three computers with a 50/50 share with MW. When I reach my goal here Einstein will trade with CPDN for at least 1 WU (3 weeks to finish @ 6000 credits to reach goal)

I really want to run Einstein full time but want a backup project in case there's problems there. (not likely) Main reason I left seti years ago. They weren't even reliable for a backup project much less being my primary.

Kind of playing around with the idea of running einstein full blast on my #1 system (DC), CPDN on wife's SC, einstein/MW 50/50 on 3rd system after I reach the stated goals. Been crunching now since 1999 started with Seti Classic, then went to Einstein and CPDN when Boinc was first released so I guess everyone can tell I am a Credit Hungry Cruncher. Such lofty goals I set!

---

Work units are coming through very intermittently.

When they do, it's full blast on MW. When they don't then it's Einstein and Malaria. Nothing for SWETI.

Typically 1 or 2 at a time, and then nothing for awhile.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

All part of the consequence of the very high efficiency of the optimized application. Until work units are released that run longer (A LOT LONGER), Milkyway is going to be swamped with too many cpu's chasing after too many mini-work units. SETI runs into that with one set of work units (which run less than a minute), when those mistakes get out there, there server (which often enough is swamped anyway) gets in real trouble. Here, the ONLY current work units are 5 minute work units -- thats a burn rate of something like 300 a day per CPU. It is an interesting control effect - -my RAC for Milkyway peaked at close to 62K a few days ago, now, even with a a lot of manual pulling, 40K or so is what I'll see. If I don't manually push things, I figure it will drop to 20K or so. So I am hoping that Travis is paying some attention to this thread (that's not at all clear at this point) and they are planning to address the issue.

Typically 1 or 2 at a time, and then nothing for awhile.

---

I'm starting to wonder if I'm doing the project a favour by participating with my fast CPU and the optimized app. Maybe it's doing more harm than good atm as the server clearly can't cope. The thing is, I tried the stock app and there was no way it would run on my system, signal 11 errors were everything I got, I crashed all WUs I had within seconds. So, go back to Malaria/Einstein/Enigma only? I'm really just trying to help.

I hear you -- I've some pretty fast workstations in the mix (including a few quad core Phenoms).

At the moment, I am leaning toward leaving them connected, but not 'helping' things by manually going after downloads -- since all the workstations are configured for multiple other projects (Spinhenge, Climate, SETI, Rosetta, World Grid, Malaria and Einstein), I've plenty of other work available from projects that are not in near dysfunctional overload, as MilkyWay currently is. Sure my overall RAC will take a hit, but until this project figures out how to really deal with the vastly more efficient optimized application being available in volume, trying to keep queues filled here is simply an exercise in futility.

I'm starting to wonder if I'm doing the project a favour by participating with my fast CPU and the optimized app. Maybe it's doing more harm than good atm as the server clearly can't cope. The thing is, I tried the stock app and there was no way it would run on my system, signal 11 errors were everything I got, I crashed all WUs I had within seconds. So, go back to Malaria/Einstein/Enigma only? I'm really just trying to help.

---

assimilator seems to be backed up. 510+ wu's

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

yes the server certainly is having some trouble dealing with workunits. we let the server catch up before issuing new work.

---

Dave Przybylo
MilkyWay@home Developer
Department of Computer Science
Rensselaer Polytechnic Institute

Work is coming through OK now. But the server status is back to 0 WUs ready to send

Been running MW only on my 4 rigs today exclusively from about 08.00 am (local). Been going OK all day, and the system seems to be keeping up just even with everyone else seeking work.

Good, and improvement from the week end.