I think the fact that GPU LTD is zero now is by design and not a bug. I am not sure what it would be if I was running another GPU project. It looks to me like they are separating the work fetch mechanisms for CPU and GPU type projects.

Phoneman1

Yes, that is the intent. Also making minor changes for non-CPU projects ...

If you are attached to lots of projects JM VII found issues that indicate that you can run dry of work with 6.6.3 ... YMMV

I had to go back to v6.3.21 because 6.6.3 Wouldn't give me any more GPU WU's no matter what I did. I tried 6.4.5 but that Version would let me run 4&1 on a Quad or 8&2 on my i7. Version 6.3.21 is the only Version so far that gives me more GPU Work & lets me run 4&1 and 8&2 ...

SAME PROBLEMS HERE!

6.6.3 will not get new work from GPUGRID for me.

Went back to 6.4.5 and instantly it got 2 new WU's for me.

They just cannot get this right can they!

SAME PROBLEMS HERE!

Is this a problem with the x64 variant - I wonder....

Anyone having problems getting GPU tasks on Win 32 bit or Linux 32 bit with 6.6.3???

Phoneman1

Version 6.3.21 is the only Version so far that gives me more GPU Work & lets me run 4&1 and 8&2 ...

Did you try 6.5.0? I found it to be surprisingly well-behaved.

MrS

---

Scanning for our furry friends since Jan 2002

Anyone having problems getting GPU tasks on Win 32 bit or Linux 32 bit with 6.6.3???
Phoneman1

No probs so far with WinXP 32 bit (BOINC 6.6.3 installed two days ago).

I am experiencing GPUGrid work fetch problems under BOINC client 6.6.3 after upgrading several days ago. I have run out of work and with repeated attempts to get work manually including resetting the project without success.

There is definitely something wrong in the BOINC client work fetch logic that allows the PC to run dry and not fetch work when there are 2 graphics cards and only one active WU being processed and none in queue.

At 2:25 PM EST today, it is trying to download work by requesting new tasks, but nothing is being returned....this could be a GPUgrid.net work availablity problem again? Or BOINC...not sure.

Neil

---

Crunching for the benefit of humanity and in memory of my dad and other family members.

There is a major bug in 6.6.3 which Dr. Anderson fixed related to the calculation of LTD. There are varying and different problems with all the 6.6.x versions from dot zero to dot three ...

I warned you below to be wary of 6.6.3 ... :)

I actually did look at the code and there was an initialization error that though I cannot predict the exact ways that it would bite you, will eventually bite you ...

Thanks Paul.

I've been watching this forum as well I'm on the alpha dist list at BOINC and like to test new releases when they come out. I'd love to get my hands on a new build to see if the fix(es) to 6.6.3 work for me. In the mean time I guess I'll have to go back to an earlier BOINC client release for now.

Neil

Works ok for me on two machines, vista64 and xp32; no problems

I just had to downgrade from 6.6.3 because it fetched way too much WUs of a CPU intense project. :-(

I thought it was OK at first also. But there was no way I could get more work to fill the queue.

6.6.3 downloaded 300 321LLR PG WU's overnight when my cache was set to 1 day.
Even after detaching from PG and reseting GPUGRID, still no new work.


Switched to 6.5.0 and its been perfect all day. It grabs GPU's no problem, and it runs 4+1 & 4.2 w/o issue so far.

Just a quick up date: No problems here. 2 rigs: Vista 64 3x 8800GS (total). Unless something changes....I'm going to stick with this for a while....

Initialization problems in code are usually the hardest to find because the system under many conditions can appear to be running correctly. In this case, the testing variable is not set with the initial value of the first project as the scanning loop begins. Now, it is entirely possible that the value that the variable has at the beginning of the loop is "close" enough so that it will do a proper scan ... but in other cases the first project in the list should be the value in the testing variable ... and it is never set ...

What that means, of course, is that you can run into trouble immediately, or more likely after running for a bit. What disappoints me the most is that no new build was made because aside this bug the build might have been the leap forward we were hoping for that finally started to address the issues we have with the GPU / CPU loads ...

Initialization problems in code are usually the hardest to find because the system under many conditions can appear to be running correctly. In this case, the testing variable is not set with the initial value of the first project as the scanning loop begins. Now, it is entirely possible that the value that the variable has at the beginning of the loop is "close" enough so that it will do a proper scan ... but in other cases the first project in the list should be the value in the testing variable ... and it is never set ...

What that means, of course, is that you can run into trouble immediately, or more likely after running for a bit. What disappoints me the most is that no new build was made because aside this bug the build might have been the leap forward we were hoping for that finally started to address the issues we have with the GPU / CPU loads ...

I don't recall you mentioning the initialize issue on the mailing list. Do you have a snippet of code you could provide where you think the issue is, or is that the LTD fix Dr A has done?

It seems the suspend/resume buttons is the only fix so far in 6.6.4. The fact they didn't want to build a new version suggests they may be aware of more bugs and want to include (or are working on) fixes for them. Or maybe they just want to give us the weekend to give 6.6.3 a shake down.

---

BOINC blog

Initialization problems in code are usually the hardest to find because the system under many conditions can appear to be running correctly.

Absolutely. This version looked good for most of yesterday and the day before on my systems. On my final check of yesterday evening it hadn't replaced a completed GPU task but was running one with one in the queue - plenty of time to sort itself out I thought - Wrong!

I've just checked for the first time today and found the last GPU task had ended nearly 2 hours before and no request for work had been made. A manual update did not request any work so I suspended the other project and tried again. That brought two GPU tasks, it then automically asked for more work and got two more. Then again but this time it was refused because I had reached 1 per core!

Clearly 6.6.3 is not to be trusted even on Win 32 so I've gone back to 6.5.0.

Phoneman1

I don't recall you mentioning the initialize issue on the mailing list. Do you have a snippet of code you could provide where you think the issue is, or is that the LTD fix Dr A has done?

It seems the suspend/resume buttons is the only fix so far in 6.6.4. The fact they didn't want to build a new version suggests they may be aware of more bugs and want to include (or are working on) fixes for them. Or maybe they just want to give us the weekend to give 6.6.3 a shake down.

The one Dr. Anderson found. However, I did look at the code change he made and in essence the first project visited should have its value stored in the scan variable. It isn't... Assuming C does initialize the value to zero, the scan value starts with this position to begin to discover the project with the largest value. If the first project has this value, it will never be discovered.

Thus, after a few days, the first project in the list will inevitably become the project with the largest value but this will not be established ... with that ... you get issues ... now I did not look at the whole set of code ... but so far I cannot recall anyone that has run 6.6.3 that has not back-leveled after a couple of days ...

Not putting up another version can suggest or imply what you said. However, this bug is so severe that you cannot use this version for testing at all ... thus you cannot check the operation of 6.6.3 and contrast it with the versions that came before ... it is too severely damaged for that ...

The one Dr. Anderson found. However, I did look at the code change he made and in essence the first project visited should have its value stored in the scan variable. It isn't... Assuming C does initialize the value to zero, the scan value starts with this position to begin to discover the project with the largest value. If the first project has this value, it will never be discovered.

Thus, after a few days, the first project in the list will inevitably become the project with the largest value but this will not be established ... with that ... you get issues ... now I did not look at the whole set of code ... but so far I cannot recall anyone that has run 6.6.3 that has not back-leveled after a couple of days ...

Not putting up another version can suggest or imply what you said. However, this bug is so severe that you cannot use this version for testing at all ... thus you cannot check the operation of 6.6.3 and contrast it with the versions that came before ... it is too severely damaged for that ...

I have 6.6.3 on three machines (non-cuda), but i'm sticking with 6.5.0 on the one cuda-capable machine for the time being. I will take the non-cuda ones back to 6.2.19.

There are a few reports of work-fetch issues popping up in boinc_alpha with the debug logging so there is a fair bit of information there for the guys to examine. I don't know if you subscribe to it or just boinc_dev? Maybe you should mention your concern with the code change.

---

BOINC blog

There are a few reports of work-fetch issues popping up in boinc_alpha with the debug logging so there is a fair bit of information there for the guys to examine. I don't know if you subscribe to it or just boinc_dev? Maybe you should mention your concern with the code change.

BOINC Dev and Projects ... I don't have a concern with the CHANGE ... just with the lack of 6.6.4 with the code change in it ...

Dr. Anderson suggested that if we wanted it we could compile our own ... which is not a really viable suggestion for most. Personally as a developer (past life) I find it a poor judgement that they would leave a version up for download with such a devastatingly subtle bug in it for people to download ...

And firing off a build in the background on their PCs that are set-up for it is not that difficult ...

.. just don't forget that these are developer versions, not even alphas. Personally I'm not that keen on testing these new versions, as most of the time something is quite broken.

MrS

---

Scanning for our furry friends since Jan 2002