@GDF

I took a look at the machine I have got that only runs GPUG with high priority and it runs fine with no discernible lag.

The machine I have a problem with runs 3 other BOINC projects and GPUG which I do have a problem with priority.

I don't think (from what I have read) Einstein makes a huge use of the GPU and maybe that's why they get away with it.

---

Radio Caroline, the world's most famous offshore pirate radio station.
Great music since April 1964. Support Radio Caroline Team -
Radio Caroline

Looks like the priority is applied to the application (going by Task Manager)

Try looking at it in Process Explorer instead.

Edit: the Einstein developers weren't aware of the difference either - http://einstein.phys.uwm.edu/forum_thread.php?id=8660&nowrap=true#109345

I was just looking at a 2003 server.

Anyone interested try here (Windows),
http://download.sysinternals.com/Files/ProcessExplorer.zip

I just deleted the swan_sync = 0 on my windows 7 computer, and yes it did become more responsive (less sluggish). Card utilization is down to 73% max, temperature is down. It runs great.

Had a unit complete without swan_sync = 0 on my windows 7 machine it took under 7 hours, with no sluggishness, compare to 8 hours with the swan_sync = 0 on the 6.13. Another unit will finish shortly, it looks like it will be under 7 hours.

This sluggishness reminds me when my computers were crunching SETI's VLAR units, though without the unit taking a long time to complete.

According to my experience with the beta 6.39/6.40 app. and the 6.14 app. the best way how to make a machine "for user usable" is to change priority of 6.14 process to low (XP) or below normal (Win 7/Vista) using e.g. Prority Tamer. Run times are very good and a machine is not sluggish, both system and Boinc GUI are responsive. Swan_syn=0 can be left to be set.

I don't understand. What did Einstein@home do?
The point is to increase utilization on heavy loaded CPU windows machines without affecting lag in the user interface.

gdf

They left the application priority at BOINC's default level, to play nice with other BOINC projects and other foreground applications the user might wish to have open: but raised the thread priority of the working thread within the application to minimise synchronisation overhead and delay.

Thread priority is discussed at http://boinc.berkeley.edu/trac/wiki/CudaApps#Threadpriority

We will do that as well, then. Only you'll have to wait 10 days as I am leaving for a 10 days conference tour to USA.

gdf

I don't understand. What did Einstein@home do?
The point is to increase utilization on heavy loaded CPU windows machines without affecting lag in the user interface.

gdf

They left the application priority at BOINC's default level, to play nice with other BOINC projects and other foreground applications the user might wish to have open: but raised the thread priority of the working thread within the application to minimise synchronisation overhead and delay.

Thread priority is discussed at http://boinc.berkeley.edu/trac/wiki/CudaApps#Threadpriority

Until then, we can adjust the priority level with the good old "3rd party" tools.

Status report: I'm crunching some GIANNI_KKFREE WUs right now, and I'm getting "only" 82-86% GPU usage with the new 6.14 client.

Until GDF returns and make the changes, I would suggest that if anyone has a display lag problem stop using SWAN_SYNC (remove the system variable and restart), or as Zoltan says use a tool to set the priority (but doing it manually could result in task failures).
For crunching-only rigs there is probably no need to do anything.
It has always been the case that some tasks are more demanding than others, so if you are running less demanding tasks, again, there is probably no need to do anything.

Update on my status report: when my Core2 Quad started to crunch another GIANNI_KKFREE WU (so now it's crunching two of these at the same time), the GPU usage is dropped to 75-80%. However there is no change in the GPU usage on my Core i7-870, when it's crunching two of these at the same time (81-85%).

Zoltan,
SWAN_SYNC on or off for both?
Any manual/tool changes in priority?
Number of cores/threads freed on each system?
What else are you crunching?

That's only a 1 to 10% difference, so might just be down to the CPU's.

SWAN_SYNC on or off for both?

On for both.

Any manual/tool changes in priority?

I'm using eFMer priority on both systems. ("Set above" - so basically no change)

Number of cores/threads freed on each system?

Core 2 Quad: 2 cores for GPUGrid 2 cores for rosetta@home
Core i7-870: 2 cores for GPUGrid 2 cores for rosetta@home (4 threads free)

What else are you crunching?

Actually I'm crunching for rosetta@home, sometimes for SIMAP.

That's only a 1 to 10% difference, so might just be down to the CPU's.

I'm sure it's down to the CPU's and to the related parts. The Core2's FSB architecture presents a bottleneck especially in dual GPU systems, in spite of this MB has two real PCIe x16 slots (both GPU runs at x16). I was noticed before that lower GPU utilizing WUs run at even lower GPU utilization on Core 2 systems than on i7s. That's why I've upgraded them.
Also, these WUs credited much-much less, while they take much longer, which is quite absurd from the cruncher's point of view.

Well, the app runs faster and uses 92% of GPU! Great, you think?

On my system (Q9650, GTX275, XP, running 4 CPU tasks - malariacontrol - in parallel to GPU task), there is an increase in the GPU usage up to 95%. The result is that the tasks are around 10% quicker.

I now can't watch HD movies or do anything else without turning GPUGrid off! The GUI lags and programs unresponsive.

Yes there is a (small) lag, but much lower than for example with Primegrid tasks. With primegrid, the system is totally unresponsive unless GPU calculation is set to stop when the system is in use. This is not the case with the new GPUGrid application. I'm am currently typing with the applicaton running.

This is only going to cost you production and I did warn you that PC's are used for other things while running GPUGrid. This is only going to stop some people helping you at all.

I don't think so. For people running GPUgrid 24/7 a 10% increase in performance is a good news. It's still possible to configure Boinc to not use the GPU when the system is in use. Other Boinc applications that use intensively the GPU are in the same situation.
Of course to adapt the system to personal needs, it could be nice to have the choice by example in the GPUGrid account setting. But this means I suppose two versions of the application or a system variable.

Hi Zoltan,
The difference would probably be slightly less if you freed up another CPU core on your C2Q; it's being compared to an i7 with 4 threads free. You could probably get away with using 5 threads on that i7 without any GPU task deficit.
PCIE 16 or 8 makes little or no difference to GPUGrid tasks, but there are still architectural differences that might make some difference (other than on the CPU).

Looks like GDF did not apply the same credit formula for the long tasks as Toni is doing. Obviously he is busy for the next 10days, so I dont expect that to be fixed retrospectively or for existing queued tasks.

Hi SK,

The difference would probably be slightly less if you freed up another CPU core on your C2Q; it's being compared to an i7 with 4 threads free.

I did it - no distinct improvement. Rosetta@home runs at low priority, so the only thing could undermine the performance of other tasks its memory usage, but it's using only 300Mbytes per task.

You could probably get away with using 5 threads on that i7 without any GPU task deficit.

Yes, but it depends on how much the GPUGrid client uses the FPU in the CPU. GPUGrid became my primary project, so I don't want to risk its performance.

PCIE 16 or 8 makes little or no difference to GPUGrid tasks, but there are still architectural differences that might make some difference (other than on the CPU).

I think lower GPU utilizing tasks use more FPU in the CPU than the higher GPU utilizing ones. They also interact more with the GPU, so the difference between the performance of PCIe x16 and x8 will be larger. Look at my i7-870's tasks. This PC has an Asus P7P55D Deluxe MB with 3 PCIe x16 slots. The 1st and the 2nd is a shared x16 slot, and the 3rd one is an independent PCIe x4. If I put in only one card to slot 1 it would have PCIe x16. If I put in the second card to slot 2 both cards would have PCIe x8. This was my original setup, and I've observed that some task types run slower on this PC, than on my Core 2 Quad (with two real PCIe x16 slots). I remember I was quite disappointed. So I moved my second card to the 3rd slot, and now the tasks are running faster on "device 0", and slower on "device 1", compared to my Core 2 Quad.

Looks like GDF did not apply the same credit formula for the long tasks as Toni is doing. Obviously he is busy for the next 10days, so I dont expect that to be fixed retrospectively or for existing queued tasks.

It's understood. But it's still distract the crunchers out there.

Toni is dealing with the low points long tasks; we will stop getting those tasks.

I have removed KKFREE3 and uploaded KKFREE4. This should be fine.

gdf

my gtx 460 still makes the computer freeze so hard that i have to suspend the gpugrid project. even with the new kkfree4 .. gpu usage at constant 90%

just like the user that downloads boinc from another site and just runs gpugrid without ever coming to this forum.. i don't want to complicate my life either with third pary softwares and getting technical about gpugrid(it all should be just <plug and play>).. i'll hold the project on suspend.

if problems go away please somebody post here that they did so i can resume.

also there's one thing i don't understand.. why are tasks tested directly on the users.. shouldn't there be some testing machines or a team of testers? i mean.. when i release a VB.NET software i don't release it without thoroughly testing it on more computers.. because releasing a software without testing increases a lot the probability of users bumping into bugs and they'll stop using the software. I think you should have a group of volunteers on which you can test the tasks before releasing them.. thus avoiding losing gpugrid users. if you guys want to adopt this system i will happily apply as a volunteer giving access with teamviewer or testing the tasks myself with given instructions.

my gtx 460 still makes the computer freeze so hard that i have to suspend the gpugrid project. even with the new kkfree4 .. gpu usage at constant 90%

just like the user that downloads boinc from another site and just runs gpugrid without ever coming to this forum.. i don't want to complicate my life either with third pary softwares and getting technical about gpugrid(it all should be just <plug and play>).. i'll hold the project on suspend.

if problems go away please somebody post here that they did so i can resume.

also there's one thing i don't understand.. why are tasks tested directly on the users.. shouldn't there be some testing machines or a team of testers? i mean.. when i release a VB.NET software i don't release it without thoroughly testing it on more computers.. because releasing a software without testing increases a lot the probability of users bumping into bugs and they'll stop using the software. I think you should have a group of volunteers on which you can test the tasks before releasing them.. thus avoiding losing gpugrid users. if you guys want to adopt this system i will happily apply as a volunteer giving access with teamviewer or testing the tasks myself with given instructions.

Hello Andrew

Right click on task bar and select TASK MANAGER select PRCESSES and find process beginning ACEMD. Highlight that process and right click on it select PRIORITY and select BELOW NORMAL. A dialogue box will appear click on CHANGE PRIORITY and you're done.

You will have to do this for every new task and when you reboot your computer.

---

Radio Caroline, the world's most famous offshore pirate radio station.
Great music since April 1964. Support Radio Caroline Team -
Radio Caroline

[

This is only going to cost you production and I did warn you that PC's are used for other things while running GPUGrid. This is only going to stop some people helping you at all.

[

I don't think so. For people running GPUgrid 24/7 a 10% increase in performance is a good news. It's still possible to configure Boinc to not use the GPU when the system is in use. Other Boinc applications that use intensively the GPU are in the same situation.
Of course to adapt the system to personal needs, it could be nice to have the choice by example in the GPUGrid account setting. But this means I suppose two versions of the application or a system variable.

my gtx 460 still makes the computer freeze so hard that i have to suspend the gpugrid project. even with the new kkfree4 .. gpu usage at constant 90%

just like the user that downloads boinc from another site and just runs gpugrid without ever coming to this forum.. i don't want to complicate my life either with third pary softwares and getting technical about gpugrid(it all should be just <plug and play>).. i'll hold the project on suspend.

if problems go away please somebody post here that they did so i can resume.

also there's one thing i don't understand.. why are tasks tested directly on the users.. shouldn't there be some testing machines or a team of testers? i mean.. when i release a VB.NET software i don't release it without thoroughly testing it on more computers.. because releasing a software without testing increases a lot the probability of users bumping into bugs and they'll stop using the software. I think you should have a group of volunteers on which you can test the tasks before releasing them.. thus avoiding losing gpugrid users. if you guys want to adopt this system i will happily apply as a volunteer giving access with teamviewer or testing the tasks myself with given instructions.

I think this proves my point.

---

Radio Caroline, the world's most famous offshore pirate radio station.
Great music since April 1964. Support Radio Caroline Team -
Radio Caroline

you have small problems while gpu grid is running.. but my computer becomes unusable while gpugrid runs.. in the past it wasn't like this.

i'm not contesting that for some people it works very well because they have a different card. but i have a gtx 460 which is bought by a lot of people and if they have the same problem the gpugrid project manager can see a serious drop in the number of people that are running gpugrid. the question is.. does he even monitor this?
and why are releases with major bugs given to users without beeing tested first on multiple computers with different video cards etc.?

from my point of view they are failing to respect BASIC logical rules and the users are paying for the mistakes made with stress.

Betting Slip:"This is only going to stop some people helping you at all."
yes.. it's a simple thing.. if you're going to say to a bunch of people <please come and help for a good cause> a lot of them will say <ok> .. but if after that you'll say <but you have to learn these technical things and wast time on this forum + jump through these loops every time you run a task> a lot of the volunteers will say <umm.. no thanks.. bye bye>