Hello,

I have downloaded this WU (http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=78693225) and it shows no progress after more than 30 minutes (0.000 %).

What happened?
What shall I do?

Boinc 6.10.36
Win7 64Bit
0.20 sse3 optimized app

thanks for your replies

I ended up aborting the 20 tasks as they all did the same thing, right now I am crunching Collatz as they go fine.

This is either another bad search, or something the .20b app cannot handle.

[edit]
Seeing that you are using a CPU app and I am running a GPU app, I am going to say that it is a bad search.

---

I ended up aborting the 20 tasks as they all did the same thing, right now I am crunching Collatz as they go fine.

This is either another bad search, or something the .20b app cannot handle.

[edit]
Seeing that you are using a CPU app and I am running a GPU app, I am going to say that it is a bad search.

I was aborting a few of them until the progress bar finally moved (above 100% and counted backwards). When they finally reported, they took almost twice as long as the "normal" WUs, and paid a liitle better. I just let 'em run!

BTW, GPUs only with no app_info file. I just let the stock app run!!

I had one go into 4 minutes and was still at 0.000%, it was still using 99% of my GPU to do nothing.

I will not crunch them.

---

http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=73633688

They pay well...417 credits...

---

Click to help Seti City.

http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=73633688

They pay well...417 credits...

Not really. I had one on a 4870 that took 830 sec/417 credits... compare that to 177sec/213 credits for the normal ones (de_s222).

Something is wrong here.

---

Join Support science! Joinc Team BOINC United now!

The old searches did run like 250s here and gave 213.76 credits

I see the new searches run from 461.05s to 663.27s for 417.48 credits

While the 461s for 417 credits is in range, 663s for the same credits is far off and should give around 565.

The progress bar first stayed at 0.0% and was above 130% when finished.

Hmmm...mine was a de_13_3s_free_5_22297_1268428455 and it ran on a stock 4870, i7-920, 3 GPU, Win x64 system...I did have 1 that ran 380sec/417cr, but that was a de_13_3s_const_1_22237_1268428453...

---

Click to help Seti City.

Similar discussion going on here

---

Go away, I was asleep

I only noticed the WU's hanging when I suspended the GPU work and it came back with >100% while it was still running. I restarted BOINC. everything was fine until I snoozed the GPU/resumed and I had to abort the WU I was on. these new WU's make my screen get a lot more wonky than when I was running the other WU's

---

Blah blah blah you know the rest

Looks bizarre!
I occasionally crunch a cosmology unit but those things are massive with few save-points, so I got to stop everything else so that those things crunch in one pass.

Turned Milkyway back on again now that I got past another large Cosmology unit, and wow... 1 minute each and results as "Completed, marked as invalid".

Seems each project has it's different requirements.
Seti has long-range requirement that can wait until mid april - therefore no rush.
Einstien appears also friendly to smaller/slower desktops too.
Milkyway needs results rather fast, so keeps bumping the slower projects that can wait longer.
Cosmology is massive with few save-points, so got to run them in one shot.

I notice there is something mentioned about scripts refusing WUs and I hope that is about some other subject, and not simply me telling BOINC to please not pick-up the next WU since I'd like to crunch a share of other projects....

Seems like whatever that was, was just a 15 minute blip and not a normal thing (now that I see a somewhat normal unit again --- Dohhh!!! it's another high priority WU again).

---

http://www.joescat.com/boinc/

I have seen this as well on multiple workstations -- the de_s222's are good, the de_12, de_13 and de_14 are bad.

---

The same for me... resetted project...
nothing helped...

---

Nothing to do with you, it's what the servers are giving us.

Wait until they go away, but crunch normally.

---

Go away, I was asleep

I have a 5970 GPU and no problems with the _13 WUs. After 150sec 0,00% it jumps to 143% and go down to 100%. Afer 195 sec I earn about 417 credits...

So, reading all that, I allowed one WU to complete and I observed the things mentioned above:

Long time progress at 0.00 %, then jumping over 100 % and counting backwards. WU is finished when progress descends to 100 %.

outcome: (optimized 0.20 sse3 64Bit on overclocked Q9550)
2.74 credits/minute (de_14_3s...) new one
1.86 credits/minute (de_s222...) old one

increase of about 47 %.

That´s fine. So I will let them run in the future and will not wonder about the strange progress bar... ;-)

That is the conclusion I have come to as well. It is just the unexpected behaviour of the progress bar that makes us suspect the validity of the WUs in question.

---

Go away, I was asleep

Hi
I have got Boinctasks and it is showing 5 hours 10 minutes 49.381% 5 hrs 19 to go

Boinc shows 5 hours 10 minutes 0% 5 hrs 19 to go

it looks like a boinc problem and the work is running properly according to Boinctasks

paul

I've had several de_14_*** tasks "successfully" complete (according to the BOINC Client) after 2 seconds. These are CPU tasks on multiple computers. The tasks were downloaded this morning and were first issue (_0 tasks). Needless to say they were invalid.

I've had many more of them over the past day or so. STD error shows nothing (as you might expect), just a really fast finish!

This is either another bad search, or something the .20b app cannot handle.

I think I have an idea what is causing the strange progress bar behaviour. The project just increased the WU size another time with this new series. Now, one WU integrates over more than 2 billion points in space for the main integral. As this is used to calculate the progress (it's just the ratio between between already completed points and total points) and the code uses only a 32bit integer to store this number it is very likely an overflow of this 32bit values. I still have to check for some side effects (especially for the GPU version as it is also used to predict the sleep times of the CPU during the GPU computations; edit: no, that part uses already doubles), but it should be easy to change this to an 64bit integer or a double value to correct the progress bar behaviour. Furtunately, this small bug shouldn't affect the actual calculation at all ;)

I expect a 0.22 release tomorrow if I find the time to compile all versions.