Using 6.4.5 last yesterday, 2 blue screens:

Error code 100000ea, parameter1 8855c2c8, parameter2 89966940, parameter3 bacfbcbc, parameter4 00000001.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

One of my teammates had the same problem on his box. If I roll back to 6.3.x - what was the last recommended version? 6.3.19?

Which driver you are using? Try the newest driver from here:

CUDA-Driver

---

178.28

Should I be using 180.60? I didn't think we were on CUDA 2.1 yet.

EDIT: Just put 6.3.19 on. Hope it goes back to being stable.

On a quad system, this causes one cpu to be dedicated to the gpugrid task. There is no need for this as I was getting 11 hours gpu completion with 5 tasks running and it is no different with 4 tasks running. This has dropped my overall credit production down.

I assume going back to 6.4.1 might fix this???


With 6.4.1, I was using about 800 seconds of CPU time to process an 11 hour ET job. Now it is taking 22,000 seconds to do the same job. There seems no way to disable the high priority for the gputask. They (BOINC) are not calculating the coprocessor efficiency and utilization correctly.

This is what I'm seeing after "upgrading" from 6.4.1 to 6.4.5. Now my quad will run only 4 tasks instead of 5. I'm going to try going back to 6.4.1.

Edit: Just moved back to 6.4.1 and the quad has returned to running 5 tasks. I'd avoid the new 6.4.5.

My 8800GT and my GTX260² are with 4+1 as fast like 3+1, only my GTX280 need the 3+1 mode, otherwise I lost a lot of time for crunching. The cards are very different in the used power of the CPU.

---

178.28

Should I be using 180.60? I didn't think we were on CUDA 2.1 yet.

EDIT: Just put 6.3.19 on. Hope it goes back to being stable.

#

Should be OK, I still use the 178.24 WHQL.

---

On a quad system, this causes one cpu to be dedicated to the gpugrid task. There is no need for this as I was getting 11 hours gpu completion with 5 tasks running and it is no different with 4 tasks running. This has dropped my overall credit production down.

I assume going back to 6.4.1 might fix this???


With 6.4.1, I was using about 800 seconds of CPU time to process an 11 hour ET job. Now it is taking 22,000 seconds to do the same job. There seems no way to disable the high priority for the gputask. They (BOINC) are not calculating the coprocessor efficiency and utilization correctly.

This is what I'm seeing after "upgrading" from 6.4.1 to 6.4.5. Now my quad will run only 4 tasks instead of 5. I'm going to try going back to 6.4.1.

Edit: Just moved back to 6.4.1 and the quad has returned to running 5 tasks. I'd avoid the new 6.4.5.

Didnt work for me - 6.4.1 picked up with the same 4 tasks and high priority for gpugrid. I suspect there is some adaptive algorithm, learning and/or a resource file that needs to be undone. If you are back at 5 tasks I suspect that very shortly they may go to high priority on you.

Did the 5 tasks come up immediately or did you to wait for a current gpugrid job to get done? When I saw there was no change I re-installed 6.4.5. At least 6.4.5 got the 11 hours correct at 6.4.1 was showing 90 days to complete.

I switched all my Box's back to 6.3.21, the 6.4.5 client was just to messed up for me. I couldn't keep a consistent amount of Wu's running, I prefer just 3 & 1 but depending on which Projects were running the amount would go from 3 & 1 to 4 & 1 to 2 & 1 & back to 3 & 1 again.

With the v6.3.21 I don't have any problems holding 3 & 1 like I Prefer to run no matter what Projects were running.

I switched all my Box's back to 6.3.21, the 6.4.5 client was just to messed up for me. I couldn't keep a consistent amount of Wu's running, I prefer just 3 & 1 but depending on which Projects were running the amount would go from 3 & 1 to 4 & 1 to 2 & 1 & back to 3 & 1 again.

With the v6.3.21 I don't have any problems holding 3 & 1 like I Prefer to run no matter what Projects were running.

Funny thing is the Linux flavor of 6.4.5 runs 4+1 consistently with no problems,as I wish,since Linux uses only about 2% of the cpu.

The dcf problems don't seem to be caused by the Boinc client as reverting back to 6.3.21 still caused dcf's to be way out of whack showing 100's of hrs to completion. All BOINC clients are doing this now that are capable of running GPU's that I have so I point my finger at the project and not the client.

The dcf problems don't seem to be caused by the Boinc client as reverting back to 6.3.21 still caused dcf's to be way out of whack showing 100's of hrs to completion

I never switched from 6.3.21, and my DCF has remained nicely just above 1. Thus, the newer clients have to be part of the equation. Did you reset the project after reverting to the older client?

The dcf problems don't seem to be caused by the Boinc client as reverting back to 6.3.21 still caused dcf's to be way out of whack showing 100's of hrs to completion

I never switched from 6.3.21, and my DCF has remained nicely just above 1. Thus, the newer clients have to be part of the equation. Did you reset the project after reverting to the older client?

No Scott I did not as I had work in queue and in progress however I did manually change the dcf values before switching and still got new work with way off estimation times....I switched from 6.3.21 to 6.4.5 because all of a sudden the client started running in high priority when GDF made the server side changes and I couldn't get new work....but you may be right ;)

I think the new clients were the culprit in jumping the DCF, but I do have the high priority issue for the GPU app even with 6.3.21 never being upgraded. I am guessing that I never had the issue of running low on work as many reported since my calc times (around 20 hours on a 9600 GSO) were fairly similar to the 24-hour thing that GDF changed on the project server (noted in another thread...can't find the post just now).

What we do not understand is that a project reset should solve the problem.

gdf

What we do not understand is that a project reset should solve the problem.

gdf

I did that & it doesn't solve the Problem, the To Completion Times were still messed up ...

What we do not understand is that a project reset should solve the problem.

gdf

Reset didn't helped me, I checked this on any PC without a new WU. I edit the DCF to one and then I get new work. If the DFC messed up again, I edit it again and get new work. When I get another Wu then one of the GPUTEST5 or GPUTEST6, I know, my DCF will be messed up again.

I think, the problem is not the application, the problem is in some WUs. I have Task 165605 and 165269 in the queue. The 165605 shows a time of 1:41:25 and the 165269 a time of 2:26. Both actual with the same DCF of 1.217038. The problem must be in the estimated time of some WUs. The real running time is not so different as the estimated time. Some are running 7 1/2 hour, others only 5 3/4 hour. That's don't reflect the big difference in the estimated time between this both WUs I have at the moment in the queue.

---

These workunits have different requests of flops in an attempt to reduce the estimated time.
The real problem is not for short estimated times as yours but long times as the client refuses the wu.


gdf

we are working on improving the Windows speed with Nvidia.
They have just sent some code to test.
g

What about those pesky x86_64bit app memory leaks? I have tried just about everything. The only solution so far is to monitor memory usage and reboot before it gets filled up.
BR,

You could try using a scheduler to automatically restart windows every so many hours / days. That may help, but you would need to install BOINC as a service, or set your PC to login automatically which is the slight downside to the plan.

---

We will distribute a WIN64 application. Working on it.
gdf

These workunits have different requests of flops in an attempt to reduce the estimated time.
The real problem is not for short estimated times as yours but long times as the client refuses the wu.


gdf

ACK, but after the run of this WU with a short estimated time the DCF jumps on 100 and I can't get a new WU without manipulate the DCF manually.

---

They just said that there is a bug on the server code.

We will try it tomorrow.

gdf

They just said that there is a bug on the server code.

We will try it tomorrow.

gdf

This bug:
- scheduler: estimate job durations based on the FLOPS estimate

for the selected APP_VERSION, rather than on the CPU benchmarks.
Otherwise estimates are wrong for GPU or multi-thread apps.