Is milkyway@home dead? It's been weeks since I was last able to download any work. It's a bit disappointing that the projects that give decent value to processor time are always out of work. I used to run seti but when they pushed the devaluation of processor time I decided never to run it again. I have to wonder if it's time to give up on BOINC.

Well there is a flurry of work going on to correct some things.
The GPU guys (like me) are soaking up everything we can get, and burning through them in seconds.
The CPU guys get a little.
Many are running scripts to request work every minute or less it seems so they hammer the server causing issues. They are simply hogging any work that is created right now.

The research team is working on an app that will specifically target the GPU guys giving us much longer work units to crunch. Read the home page.

But no, it is not dead... just struggling right now.

---

Try CPDN. Non-GPU, CPU only, and plenty of work.

---

Cheers,

PeterV

.

Is milkyway@home dead? It's been weeks since I was last able to download any work. It's a bit disappointing that the projects that give decent value to processor time are always out of work. I used to run seti but when they pushed the devaluation of processor time I decided never to run it again. I have to wonder if it's time to give up on BOINC.

There are about 40 or more projects that are currently issuing work. If you are leaning towards increasing your award, or keeping it high rather than the type of project then there are a few projects that are not bad, not necessarily as good as MW ...

The suggestion of CPDN is a good one as I have found them historically pretty good especially when you consider that they will pay even if the task crashes late in the process, you will have been paid up to the last trickle. ABC is good also with a sliding scale that increases to a maximum of 1K.

For my part I seem to have less trouble getting tasks on my non-GPU machines than the one that I WANT to get the work ...

Just to keep the record straight, GPU Grid is off line, so is Einstein, and MW is having trouble keeping enough work on hand to satisfy the demands. This is NORMAL ... as in historically speaking having a number of projects having troubles at the same time.

Am I "bent" by the fact that I cannot have work to keep my GPUs busy? Sure ... I loved earning ~100K per day at GPU Grid ... but, for the time they are off-line I am doing SaH Beta just to keep my equipment warm ...

My GPUGrid nehalem/nvidias share with CPDN, so even without GPUGrid work they're not exactly bored, even if the GPUs are currently idled.

---

Cheers,

PeterV

.

A few of my computers weren't getting any WU from MW for weeks as well, but at the same time two of them were getting a steady stream, and without any scripts. I now have those computers that weren't getting MW WU crunching for either ABC or CPDN.

I have two computers with cpu only and for the past few days have had hardly any work. As I run seti@home also,Im not worried about my comps running dry. Unless there is a melt down between projects like a few weeks ago.

---

Its hardly dead, just at a rough patch, that's all. The project leader is working hard to get the issues resolved.

---

For the fist time in a couple of weeks my machine has had a steady supply of units for the 4 CPU's all day.

---

Mars rules this confectionery war!

My GPUGrid nehalem/nvidias share with CPDN, so even without GPUGrid work they're not exactly bored, even if the GPUs are currently idled.

verstapp, almost all my PCs/laptops that are crunching MilkyWay have a CPDN task constantly on the go. One, because MilkyWay allows you to crunch with the CPU, and secondly because there is something crunching (CPDN) when there is no MW work available.

What I havn't been able to figure out on my Core2's is how to get two CPDN tasks crunching when MW work is absent. (I manage to get 2 CPDN crunching, but sometimes it stops the MW work when there is some.)

---

What I havn't been able to figure out on my Core2's is how to get two CPDN tasks crunching when MW work is absent. (I manage to get 2 CPDN crunching, but sometimes it stops the MW work when there is some.)

If you're using BOINC v5.10x you can run BOINC Studio and set an individual priority for each project.

---

me@rescam.org

What I havn't been able to figure out on my Core2's is how to get two CPDN tasks crunching when MW work is absent. (I manage to get 2 CPDN crunching, but sometimes it stops the MW work when there is some.)

If you're using BOINC v5.10x you can run BOINC Studio and set an individual priority for each project.

Ah, now there's a thing. I always assumed I should be running the latest versions of BOINC to get the best out of it with the ATI cards. Currently it's at 6.6.20

I wonder if going to 5.10x is OK with the ATI cards, or is this best just for CPU crunching?

---

I wonder if going to 5.10x is OK with the ATI cards, or is this best just for CPU crunching?

For crunching with the ATI cards at this moment it shouldn't matter, as you're using the anonymous platform file (app_info.xml) to tell BOINC what application to use, while the brook.dll file tells the application that everything happens on the coprocessor.

---

Jord.

The BOINC FAQ Service.

Where can I get Boinc Studio. The Website is down

Is milkyway@home dead? It's been weeks since I was last able to download any work.

There is activity, see the GPU messages

There is a problem. The server status indicates there are 813 units ready, but my boinc gets: No work available.

Is milkyway@home dead? It's been weeks since I was last able to download any work.

There is activity, see the GPU messages

There is a problem. The server status indicates there are 813 units ready, but my boinc gets: No work available.

Dont forget that the server_status page is a snapshot approx 10 minutes ago. So those WUs could have been snapped up.

Also, the server can only dole out so many WUs at a time to people. So if it can only handle giving out to 20 people at a time, if 25 people are connecting to it at that time, 5 people will get diddly squat. (I'm guessing the number is like 3 at a time and about 40 people are trying to connect at each point in time)

---

Is milkyway@home dead? It's been weeks since I was last able to download any work.

There is activity, see the GPU messages

There is a problem. The server status indicates there are 813 units ready, but my boinc gets: No work available.

Dont forget that the server_status page is a snapshot approx 10 minutes ago. So those WUs could have been snapped up.

Also, the server can only dole out so many WUs at a time to people. So if it can only handle giving out to 20 people at a time, if 25 people are connecting to it at that time, 5 people will get diddly squat. (I'm guessing the number is like 3 at a time and about 40 people are trying to connect at each point in time)

The limit is not the number of connections to the scheduler per se. It has to do with how many tasks the scheduler can keep in active memory ready to be sent out on request, and how fast that queue can be refilled from mass storage.

Alinator

--<snip>--
There is a problem. The server status indicates there are 813 units ready, but my boinc gets: No work available.

Dont forget that the server_status page is a snapshot approx 10 minutes ago. So those WUs could have been snapped up.
--<snip>--

Sorry, but that kind of advice appears to me to be misleading, and there's already too much confusion and frustration as it is. So, until Travis & Co. kindly tell us what's really happening on the server, please avoid statements of "fact" unless it is fact.

To wit: I have never seen the ready units level below 400, and I've checked many, many, many, many times. If it ever fell to zero, then 10 minutes later (or whenever the refresh happened), it would have shown as zero (or very, very low). It never has for me. So I don't believe this idea that the refresh delay hides an empty supply.

Now, if work is being prepared in batches rather than continuously, and if the refresh happens at the same time a new batch is prepared, then your speculation has merit.

Does anyone know?

---

--Bill

I never mentioned or alluded to the fact that the server could have produced more. I know it could have, but what you're seeing is just that single snapshot on server_status. Anything between those snapshots is educated guesses or speculation - you'll never get 'fact' unless it comes direct from the higher ups.

Now for a fact - Travis mentioned in the not too distant past that the server is designed to never go below 300 avail WUs at one time.

Alinator's explanation sounds good - more of a throughput issue via memory than anything else - an extension and slight modification on my idea. (But Bill, is this a fact? You decide for yourself, however I find it more than plausible.)

---