Didn't see a post about this so thought I should put one up.

Change Log:

- client: tweak CPU scheduling policy. When there's a coproc job:
Windows: don't saturate CPUs
Unix: saturate CPUs

- client: in round-robin simulation, remove code that sets CPU shortfall for projects with no active results.

This is now wrong because there coproc apps might have pending results. Also remove nidle_cpus > 0 conditional that increments CPU shortfall; I think this is vestigial code.

- client: include deviceOverlap and multiProcessorCount in XML for CUDA devices. They were mistakenly omitted.

- client: in round-robin simulation, don't count a project in total resource share if it has coproc jobs and no CPU jobs.

- MGR: fix the terms of use wizard page.

Original Post:
http://boinc.berkeley.edu/dev/forum_thread.php?id=2518&nowrap=true#21694

Download area:
http://boinc.berkeley.edu/download_all.php

Didn't see a post about this so thought I should put one up.

Change Log:

- client: tweak CPU scheduling policy. When there's a coproc job:
Windows: don't saturate CPUs
Unix: saturate CPUs

- client: in round-robin simulation, remove code that sets CPU shortfall for projects with no active results.

This is now wrong because there coproc apps might have pending results. Also remove nidle_cpus > 0 conditional that increments CPU shortfall; I think this is vestigial code.

- client: include deviceOverlap and multiProcessorCount in XML for CUDA devices. They were mistakenly omitted.

- client: in round-robin simulation, don't count a project in total resource share if it has coproc jobs and no CPU jobs.

- MGR: fix the terms of use wizard page.

Original Post:
http://boinc.berkeley.edu/dev/forum_thread.php?id=2518&nowrap=true#21694

Download area:
http://boinc.berkeley.edu/download_all.php

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

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

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

Maybe the DCF problem will be solve.

Jim PROFIT

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

I found out about the DCF, this is because the client was changed to use FLOPS counting for GPU tasks, The reason it is off is the FLOPS estimate in the work unit is too low. The old version client works because it does not use that value. GDF will correct in new work units.

I do believe I have had a more steady flow of work in 6.4.5 but only 1 at a time so far as the DCF is too high. Once the correct FLOPS value is used, it should correct back to near 1 (over several task) and resume normal operation.

I did get more work, automatically, after one finished, well 49 minutes after, but at least that is better than having no work and two just waiting to report needing manual intervention as in 6.4.4

12/10/2008 10:00:30 PM|GPUGRID|Finished upload of JZa1465-GPUTEST5-15-20-acemd_0_2
...
12/10/2008 10:49:08 PM|GPUGRID|Sending scheduler request: To fetch work. Requesting 16354 seconds of work, reporting 1 completed tasks
12/10/2008 10:49:13 PM|GPUGRID|Scheduler request completed: got 1 new tasks
...
12/10/2008 10:50:11 PM|GPUGRID|Finished download of no10932-GPUTEST5-14-grama.ionized.psf
12/10/2008 10:50:12 PM|GPUGRID|Starting no10932-GPUTEST5-14-20-acemd_0
12/10/2008 10:50:12 PM|GPUGRID|Starting task no10932-GPUTEST5-14-20-acemd_0 using acemd version 653

Just upgraded to 6.4.5. There is 1 GPU task running and none in the cache. I have work buffer set at 1.0 days and connect every 0.1 days. BOINC use to cache upto 4 wu's, but now get the following message on the work request.

12/12/2008 6:26:57 AM|GPUGRID|Sending scheduler request: To fetch work. Requesting 99540 seconds of work, reporting 0 completed tasks
12/12/2008 6:27:12 AM|GPUGRID|Scheduler request completed: got 0 new tasks
12/12/2008 6:27:12 AM|GPUGRID|Message from server: No work sent
12/12/2008 6:27:12 AM|GPUGRID|Message from server: (won't finish in time) BOINC runs 99.9% of time, computation enabled 100.0% of that

I haven't touch my installations since 6.3.21 but I get the same message too now.
____________

I got the same message on 2 machines running 6.3.19.

It appears with a change in the client the DCF is getting maxed out to 100, this started with 6.4.3. What happens is this cause the cleint to think that every GPUGRID task is going to take way longer than it does. The 4 day deadline, to the client is too short, and it runs the task in high priority, not fetching more work either.

It sounds as though this will self-correct eventually, though I was hoping it would revert back to previous functionality after doing a fresh uninstall/install of the BOINC 6.3.19 client. :-(

I am getting WU's with 282 and 538 hour to completion times- everything running high priority :(
6.4.5, XP Home

I've changed the DCF-Factor on my machines to a more realistic value and now my boxes (all Quads) are running with a nearly correct estimated time, 8 hours instead of 6:30h. Now I have the next problem. I've running the additional projects CPDN, PrimeGrid, WCG and MilkyWay. To get a new WU I have to stop 3 projects, especially CPDN (work for over 800 hours) and WCG (work for 48 hours). My workcache is set to 2 days. When I have downloaded on this way a second WU, the timer shows 24 hours for the next call. But my GTX280 need only 13 hours for this 2 WUs. So, If I'm absent and can't make a call manually, my PC will be 11 hours without new work. This should be corrected.
____________

I've changed the DCF-Factor on my machines to a more realistic value and now my boxes (all Quads) are running with a nearly correct estimated time, 8 hours instead of 6:30h. Now I have the next problem. I've running the additional projects CPDN, PrimeGrid, WCG and MilkyWay. To get a new WU I have to stop 3 projects, especially CPDN (work for over 800 hours) and WCG (work for 48 hours). My workcache is set to 2 days. When I have downloaded on this way a second WU, the timer shows 24 hours for the next call. But my GTX280 need only 13 hours for this 2 WUs. So, If I'm absent and can't make a call manually, my PC will be 11 hours without new work. This should be corrected.

Every gpu (9800gtx+) task is running at high priority and there is no need. Each task finishes in under 11 hours iregardless of the priority and the deadlines are at least 4 days away.

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.

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?

So is 6.4.5 still the suggested version- hope for some quick fixes, or roll back to version 'x'?

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?

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.

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.

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.

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.

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

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?

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

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,

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

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

We will try it tomorrow.

gdf

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?

I also rollback to 6.3.21; almost everything is fine now.

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.

How could it be, that the 6.4.5 is be the "Recommended version" here and on the Berkeley-Server? All is running fine with the 6.3.21, with the 6.4.2 and 6.4.3 is a only a little problem the DCF (HighPrioMode), but with the 6.4.5 you can't run GPUGrid without babysitting the boxes all the time.

Is the failure only on the server of GPUGrid and come with the calculated estimted time with the WU on our boxes? Then please stop this WUs with the wrong calculated time.
____________

On my Windows x64 and BOINC-Manager x64 i got the Message:
18.12.2008 09:50:19|GPUGRID|Message from server: No work sent
18.12.2008 09:50:19|GPUGRID|Message from server: Full-atom molecular dynamics on Cell processor is not available for your type of computer.
18.12.2008 09:50:19|GPUGRID|Message from server: Full-atom molecular dynamics for Cell processor is not available for your type of computer.
18.12.2008 09:50:19|GPUGRID|Message from server: Full-atom molecular dynamics is not available for your type of computer.

Is there no Client for?

with the 6.4.2 and 6.4.3 is a only a little problem the DCF (HighPrioMode), but with the 6.4.5 you can't run GPUGrid without babysitting the boxes all the time.

Well, I just built a new computer with a Nvidia 9800 GT with 1 G VRAM and got three tasks right off the bat. I could not log into the web site so I went with NNW until that was resolved.

I checked this morning and Voila, my account allowed me to log on (Praise something)...

But, when I tried to fetch work... I got the message that there was no work for my Cell processor type (Message from server: Full-atom molecular dynamics for Cell processor is not available for your type of computer.)

I did a project reset and it looks like it is downloading a task ...

And an immediate failure with computation error.

So, two successes and two computation errors. Is this common?

I am running video driver 6.14.11.8048 and BOINC 6.4.5

Hmmm, it is downloading another task ...

Computation error ...

Another computation error ...

{edit}Down-leveled BOINC to 6.2.19 but have the 0 seconds asked for ... so will have to wait to see if I get more work later{/edit}

Just upgraded to 6.4.5 and did a reset. Got two WU for my 2 280's and when it tried to download more got this:

12/18/2008 9:32:47 PM|GPUGRID|Sending scheduler request: Requested by user. Requesting 518336 seconds of work, reporting 0 completed tasks
12/18/2008 9:32:52 PM|GPUGRID|Scheduler request completed: got 0 new tasks
12/18/2008 9:32:52 PM|GPUGRID|Message from server: No work sent
12/18/2008 9:32:52 PM|GPUGRID|Message from server: Full-atom molecular dynamics for Cell processor is not available for your type of computer.
12/18/2008 9:32:52 PM|GPUGRID|Message from server: Full-atom molecular dynamics on Cell processor is not available for your type of computer.

My estimated completion time started low and is going up rather that starting high and going down. However they are not running in high priority and show only 0.03 CPU's. That would be a huge improvement over 0.9 CPU's in 6.3.21.

Now all I need to do is sleep infront of my rig with the alarm set every 6 hrs to download new WU.

Glad tomorrow is the last day of work for 2 wks.

Pat

Update: Changed the number of days of work to 4 and was able to download two more WU. We'll see in the morning if I don't have to babysit.

No more "babysitting" with 6.4.5 ;-)

I run one GPU on Vista-32 and another on Vista-64 with 6.4.5 BOINC. The all on to similar hardw. After some days of troubles and newbee try-&-fail, I may report that I solved my issues on the 64-system by exclusively run others Boinc 64-applications at the same time with the GPU-apps. Last day I tried to extend again the range of apps running on the 64-sys with some 32-apps and it didn't took many hours before I got a sys.restart to handle with.
Solution was to detach again all apps that do not run on 64 bits arch. and to synchronize right after the restart. I didn't inquire which one of those 32-apps that caused the mess. & I do not intend to do so either... Merry Christmas !

I ment CUDA-apps on GPU... Not only GPU!

It doesn't even think to get new WUs for my GPU. But even if I force it to get WUs, there are running only 2 tasks: gpugrid and CPU-task. What's wrong?

It seems that all of us using different boic managers 6.4.5.....

It doesn't even think to get new WUs for my GPU. But even if I force it to get WUs, there are running only 2 tasks: gpugrid and CPU-task. What's wrong?

It seems that all of us using different boic managers 6.4.5.....

Using 6.5.0, runnig 3 tasks at last. acemd takes 10 to 15% CPU time.

Using 6.5.0, runnig 3 tasks at last. acemd takes 10 to 15% CPU time.