Advanced search

Message boards : News : New application acemdlong 6.14 is out

Author Message
Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1895
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21389 - Posted: 12 Jun 2011 | 8:15:26 UTC

This new application mainly present changes in terms of the science.

gdf

Betting Slip
Send message
Joined: 5 Jan 09
Posts: 589
Credit: 2,039,148,450
RAC: 1,508,450
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21390 - Posted: 12 Jun 2011 | 8:42:11 UTC - in response to Message 21389.

I would appreciate it if you could elaborate and I'm sure other GPUgrid contributors would.


____________

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1895
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21394 - Posted: 12 Jun 2011 | 17:23:27 UTC - in response to Message 21391.

The old application was 6 months old and several things have changed.
Most important are the ability to read the latest CHARMM forcefield and a fix in the wrapping of periodic boundary conditions.

gdf

Betting Slip
Send message
Joined: 5 Jan 09
Posts: 589
Credit: 2,039,148,450
RAC: 1,508,450
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21395 - Posted: 12 Jun 2011 | 20:57:32 UTC - in response to Message 21394.

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

I now can't watch HD movies or do anything else without turning GPUGrid off!

The GUI lags and programs unresponsive.

Windows 7 - Swan Sync - 4GB Ram - GTX460 IGig

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.


____________

Toni
Volunteer moderator
Project administrator
Project developer
Project scientist
Send message
Joined: 9 Dec 08
Posts: 592
Credit: 4,273,184
RAC: 0
Level
Ala
Scientific publications
watwatwatwat
Message 21396 - Posted: 12 Jun 2011 | 21:16:09 UTC - in response to Message 21395.

Does anybody know if GUI slowdowns also happen without SWAN_SYNC?

Bedrich Hajek
Send message
Joined: 28 Mar 09
Posts: 340
Credit: 3,821,232,509
RAC: 940,467
Level
Arg
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21397 - Posted: 12 Jun 2011 | 22:08:04 UTC

My Windows 7 computer with the GTX 480 card just successfully completed the first of these units. It took a little over 6 hours to finish compared to about 8 hours for the 6.13. Card utilization was up to 85% compared to the mid 60's for 6.13. The card temperature reached into the 80's compared to the 70's for 6.13 at 100% fan speed. Except for the fact that the computer is sluggish and slow to respond, nothing bad is happening.

My Windows xp computer with the GTX 285 shows no significant improvement in performances. Card utilization increased from 95% to 97%. The sluggishness is less noticeable on this one.

Both are running swan_sync = 0.

Bedrich Hajek
Send message
Joined: 28 Mar 09
Posts: 340
Credit: 3,821,232,509
RAC: 940,467
Level
Arg
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21398 - Posted: 12 Jun 2011 | 23:03:43 UTC - in response to Message 21396.

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.

Dirk
Send message
Joined: 10 Oct 08
Posts: 18
Credit: 39,100,916
RAC: 0
Level
Val
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21399 - Posted: 12 Jun 2011 | 23:23:39 UTC - in response to Message 21397.

My Windows 7 computer with the GTX 480 card just successfully completed the first of these units. It took a little over 6 hours to finish compared to about 8 hours for the 6.13. Card utilization was up to 85% compared to the mid 60's for 6.13. The card temperature reached into the 80's compared to the 70's for 6.13 at 100% fan speed. Except for the fact that the computer is sluggish and slow to respond, nothing bad is happening.

My Windows xp computer with the GTX 285 shows no significant improvement in performances. Card utilization increased from 95% to 97%. The sluggishness is less noticeable on this one.

Both are running swan_sync = 0.


Hmm strange. My GTX480 also runs on win7 64 bit with swan sync on and I have no sluggishness at all. Utilisation is about the same as yours at 84%. My card is slightly overclocked at 750core 1500shader 1900mem and my temps are 88c at 66% fan speed (standard fan setting for the night) and about 71c at 82% fan speed (daytime setting).

My current 6.14 WU also seems to be aiming at about a 6 hour completion time.

Anyways, I'm happy with the higher utilisation, used to be a bit low on my card.

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1895
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21403 - Posted: 13 Jun 2011 | 7:52:42 UTC - in response to Message 21397.

I was not expecting the machine to become faster if you were using SWAN_SYNC already. Strange.
All these utilization things are really system dependent. The change of above average priority should not produce any sluggishness. It should be transparent to you. Maybe try to remove SWAN_SYNC.

gdf


My Windows 7 computer with the GTX 480 card just successfully completed the first of these units. It took a little over 6 hours to finish compared to about 8 hours for the 6.13. Card utilization was up to 85% compared to the mid 60's for 6.13. The card temperature reached into the 80's compared to the 70's for 6.13 at 100% fan speed. Except for the fact that the computer is sluggish and slow to respond, nothing bad is happening.

My Windows xp computer with the GTX 285 shows no significant improvement in performances. Card utilization increased from 95% to 97%. The sluggishness is less noticeable on this one.

Both are running swan_sync = 0.

Betting Slip
Send message
Joined: 5 Jan 09
Posts: 589
Credit: 2,039,148,450
RAC: 1,508,450
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21404 - Posted: 13 Jun 2011 | 7:55:16 UTC - in response to Message 21403.

See this post http://www.gpugrid.net/forum_thread.php?id=2546#21400


____________

Betting Slip
Send message
Joined: 5 Jan 09
Posts: 589
Credit: 2,039,148,450
RAC: 1,508,450
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21405 - Posted: 13 Jun 2011 | 8:05:30 UTC - in response to Message 21403.
Last modified: 13 Jun 2011 | 8:14:33 UTC

I was not expecting the machine to become faster if you were using SWAN_SYNC already. Strange.
All these utilization things are really system dependent. The change of above average priority should not produce any sluggishness. It should be transparent to you. Maybe try to remove SWAN_SYNC.

gdf


My Windows 7 computer with the GTX 480 card just successfully completed the first of these units. It took a little over 6 hours to finish compared to about 8 hours for the 6.13. Card utilization was up to 85% compared to the mid 60's for 6.13. The card temperature reached into the 80's compared to the 70's for 6.13 at 100% fan speed. Except for the fact that the computer is sluggish and slow to respond, nothing bad is happening.

My Windows xp computer with the GTX 285 shows no significant improvement in performances. Card utilization increased from 95% to 97%. The sluggishness is less noticeable on this one.

Both are running swan_sync = 0.



I don't believe it has anything to do with change in CPU priority, This WU http://www.gpugrid.net/workunit.php?wuid=2525127 finished 6000 seconds faster and this one 7000 secs faster http://www.gpugrid.net/workunit.php?wuid=2528082 on GTX460 machines that were already using sync. I think you have optimized the app to use more GPU to the detriment of some machines and that will inevitably lead to people joining GPUG and leaving when they discover lag.

I will try turning off Swan when I get to my comps but fear that will only mitigate the problem and not eliminate it.
____________

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21409 - Posted: 13 Jun 2011 | 9:10:37 UTC - in response to Message 21405.
Last modified: 13 Jun 2011 | 21:23:03 UTC

I noticed a slight increase in temperature, higher GPU utilization and on at least one system an improvement in task performances (they run faster). However I do see some GUI lag when browsing/normal desktop usage. You would normally expect higher performance when GPU utilization increases, so no surprise there. The fact that I only saw a small rise in performance is because the systems I have are high end and had high GPU utilization before the 6.14 move (90%+, often around 95%), so 98 is not that much.

I suggest you try normal priority as opposed to above normal priority.

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1895
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21410 - Posted: 13 Jun 2011 | 9:37:09 UTC - in response to Message 21409.
Last modified: 13 Jun 2011 | 9:39:15 UTC

There should be no lag. So maybe we want to remove the higher priority on the gpu with the display.
I would have expected more lags due to SWAN_SYNC than the priority, but it seems not to be the case.
gdf

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1895
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21412 - Posted: 13 Jun 2011 | 9:39:38 UTC - in response to Message 21410.

Now acemd2 is also out.

gdf

Richard Haselgrove
Send message
Joined: 11 Jul 09
Posts: 790
Credit: 1,422,925,145
RAC: 1,353,568
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21413 - Posted: 13 Jun 2011 | 9:43:20 UTC

Is the new higher priority being applied at the application level, or the thread level?

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21414 - Posted: 13 Jun 2011 | 9:52:54 UTC - in response to Message 21412.

I think this was also the problem with eFMer Priority; made the systems responsiveness sluggish (as well as not being as fast as using SWAN_SYNC).

Removing the higher priority on the gpu with the display should work well, if you can do that.

Looks like the priority is applied to the application (going by Task Manager):
acemdlong_6.14_windows_intel86__cuda*32 - Priority = Above Normal.

Betting Slip
Send message
Joined: 5 Jan 09
Posts: 589
Credit: 2,039,148,450
RAC: 1,508,450
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21416 - Posted: 13 Jun 2011 | 10:08:27 UTC - in response to Message 21414.

I think it maybe the CPU priority and you're right.

I lowered the app priority to "below normal" on a problem machine and walla! it all came back I can now play HD movies and run progs and still use 90% GPU for GPUGrid. Happy!

Your path is clear.

____________

Richard Haselgrove
Send message
Joined: 11 Jul 09
Posts: 790
Credit: 1,422,925,145
RAC: 1,353,568
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21417 - Posted: 13 Jun 2011 | 10:12:18 UTC - in response to Message 21414.
Last modified: 13 Jun 2011 | 10:17:08 UTC

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

Betting Slip
Send message
Joined: 5 Jan 09
Posts: 589
Credit: 2,039,148,450
RAC: 1,508,450
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21418 - Posted: 13 Jun 2011 | 10:28:00 UTC - in response to Message 21414.

Setting the app to NORMAL priority seems to work as well.
____________

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1895
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21419 - Posted: 13 Jun 2011 | 10:30:27 UTC - in response to Message 21418.

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

Betting Slip
Send message
Joined: 5 Jan 09
Posts: 589
Credit: 2,039,148,450
RAC: 1,508,450
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21420 - Posted: 13 Jun 2011 | 10:36:49 UTC - in response to Message 21419.

@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.
____________

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21422 - Posted: 13 Jun 2011 | 10:43:45 UTC - in response to Message 21417.

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

Bedrich Hajek
Send message
Joined: 28 Mar 09
Posts: 340
Credit: 3,821,232,509
RAC: 940,467
Level
Arg
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21423 - Posted: 13 Jun 2011 | 10:46:31 UTC - in response to Message 21398.

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.

Profile nenym
Send message
Joined: 31 Mar 09
Posts: 136
Credit: 589,129,600
RAC: 270,074
Level
Lys
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21424 - Posted: 13 Jun 2011 | 12:38:36 UTC
Last modified: 13 Jun 2011 | 12:39:45 UTC

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.

Richard Haselgrove
Send message
Joined: 11 Jul 09
Posts: 790
Credit: 1,422,925,145
RAC: 1,353,568
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21425 - Posted: 13 Jun 2011 | 12:54:35 UTC - in response to Message 21419.

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

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1895
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21426 - Posted: 13 Jun 2011 | 14:35:59 UTC - in response to Message 21425.

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

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1844
Credit: 10,641,103,144
RAC: 9,944,131
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21429 - Posted: 13 Jun 2011 | 21:35:37 UTC - in response to Message 21426.
Last modified: 13 Jun 2011 | 21:37:14 UTC

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.

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21430 - Posted: 13 Jun 2011 | 21:45:05 UTC - in response to Message 21426.
Last modified: 13 Jun 2011 | 21:49:09 UTC

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.

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1844
Credit: 10,641,103,144
RAC: 9,944,131
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21433 - Posted: 13 Jun 2011 | 22:13:04 UTC - in response to Message 21429.
Last modified: 13 Jun 2011 | 22:14:06 UTC

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%).

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21436 - Posted: 13 Jun 2011 | 23:21:02 UTC - in response to Message 21433.
Last modified: 13 Jun 2011 | 23:29:13 UTC

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.

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1844
Credit: 10,641,103,144
RAC: 9,944,131
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21438 - Posted: 14 Jun 2011 | 6:57:27 UTC - in response to Message 21436.

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.

[AF>Belgique] bill1170
Send message
Joined: 4 Jan 09
Posts: 12
Credit: 377,486,777
RAC: 39,693
Level
Asp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21439 - Posted: 14 Jun 2011 | 9:18:53 UTC - in response to Message 21395.

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.

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21440 - Posted: 14 Jun 2011 | 10:27:35 UTC - in response to Message 21439.

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.

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1844
Credit: 10,641,103,144
RAC: 9,944,131
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21451 - Posted: 14 Jun 2011 | 16:21:14 UTC - in response to Message 21440.

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.

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21454 - Posted: 14 Jun 2011 | 17:49:29 UTC - in response to Message 21451.

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

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1895
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21461 - Posted: 15 Jun 2011 | 13:41:20 UTC - in response to Message 21454.

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

gdf

Andrew3000
Send message
Joined: 1 Feb 10
Posts: 24
Credit: 1,220,848
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwatwat
Message 21465 - Posted: 16 Jun 2011 | 5:39:13 UTC - in response to Message 21461.
Last modified: 16 Jun 2011 | 6:03:19 UTC

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.

Betting Slip
Send message
Joined: 5 Jan 09
Posts: 589
Credit: 2,039,148,450
RAC: 1,508,450
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21466 - Posted: 16 Jun 2011 | 7:55:27 UTC - in response to Message 21465.

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.


____________

Betting Slip
Send message
Joined: 5 Jan 09
Posts: 589
Credit: 2,039,148,450
RAC: 1,508,450
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21467 - Posted: 16 Jun 2011 | 8:01:49 UTC - in response to Message 21439.

[

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.


____________

Andrew3000
Send message
Joined: 1 Feb 10
Posts: 24
Credit: 1,220,848
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwatwat
Message 21470 - Posted: 16 Jun 2011 | 8:54:10 UTC - in response to Message 21467.
Last modified: 16 Jun 2011 | 9:04:19 UTC

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>

Betting Slip
Send message
Joined: 5 Jan 09
Posts: 589
Credit: 2,039,148,450
RAC: 1,508,450
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21471 - Posted: 16 Jun 2011 | 9:01:29 UTC - in response to Message 21470.

Andrew, have you tried altering priority as I posted above?


____________

Andrew3000
Send message
Joined: 1 Feb 10
Posts: 24
Credit: 1,220,848
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwatwat
Message 21472 - Posted: 16 Jun 2011 | 9:16:28 UTC - in response to Message 21471.

yes.. it works.. but what about the people who download boinc from the berkley site and select gpugrid and don't visit this forum?

anyway.. jumping through loops is not acceptable.. i'll suspend the gpugrid project until it's fixed.

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1895
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21476 - Posted: 16 Jun 2011 | 12:37:43 UTC - in response to Message 21472.

You don't need to play with priorities. Just wait a week and we will remove this.
It was a test to see if a little increase in priority would make things better as the performance on windows machines is sometime half of what it should be.
We were hoping to use a user preference for it, but it is not possible until we update the server software.

gdf

Andrew3000
Send message
Joined: 1 Feb 10
Posts: 24
Credit: 1,220,848
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwatwat
Message 21479 - Posted: 16 Jun 2011 | 15:21:39 UTC - in response to Message 21476.
Last modified: 16 Jun 2011 | 15:23:47 UTC

sure gdf.. i have patience.. but you need to ask yourself: does the standard user have it?

i have a 7000 lines vb.net project myself and i understand the problems that come with big projects.. but i don't understand why this severe bug got out to the users.. and i belive it is a big mistake that it ever got out. maybe you should have released it when you had the time to work on the bugs and maybe it should have been tested well before the release.

Dirk
Send message
Joined: 10 Oct 08
Posts: 18
Credit: 39,100,916
RAC: 0
Level
Val
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21481 - Posted: 16 Jun 2011 | 16:23:40 UTC - in response to Message 21479.

sure gdf.. i have patience.. but you need to ask yourself: does the standard user have it?

i have a 7000 lines vb.net project myself and i understand the problems that come with big projects.. but i don't understand why this severe bug got out to the users.. and i belive it is a big mistake that it ever got out. maybe you should have released it when you had the time to work on the bugs and maybe it should have been tested well before the release.


While I think your criticism is valid I do think you're overestimating the impact. People with a GPU capable of crunching for GPUGRID will mostly be gamers and other enthusiasts who should definitely be keeping an eye on the system and the projects it's running. For starters a certain version (and above) of nvidia drivers need to be installed to even be able to run the tasks. I'd say updating drivers is much more work than going to the projects forums to see if anything is known about a problem one is having and then perhaps changing a tasks priority. I doubt GPUGRID really has many "standard" users anyway, it's not like one can just attach a work pc to the project and forget about it from then on.

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1895
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21482 - Posted: 16 Jun 2011 | 18:24:18 UTC - in response to Message 21479.

It is not a bug. Many people with top GPUs would not have problems with that increase in priority (in fact, it was the default in BOINC at first).

Everytime there is a change, there are problems because the heterogeneity is very large out there. Yet, we need to progress and accept to correct changes. We are going to change the priority only on device 0, the one attached to the display.

In the future, it will be a project preference.
gdf

sure gdf.. i have patience.. but you need to ask yourself: does the standard user have it?

i have a 7000 lines vb.net project myself and i understand the problems that come with big projects.. but i don't understand why this severe bug got out to the users.. and i belive it is a big mistake that it ever got out. maybe you should have released it when you had the time to work on the bugs and maybe it should have been tested well before the release.

Andrew3000
Send message
Joined: 1 Feb 10
Posts: 24
Credit: 1,220,848
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwatwat
Message 21483 - Posted: 17 Jun 2011 | 6:02:17 UTC - in response to Message 21482.
Last modified: 17 Jun 2011 | 6:05:35 UTC

Everytime there is a change, there are problems because the heterogeneity is very large out there.

i know (it is the standard problem with big projects) but what i don't understand is why the tasks aren't tested first in a "private" enviroment (with volunteer users or something) that reflects the complex structure of the public users.

i even had this computer freeze problem when on a project.. the software was tested on multiple computers before the release.. i fixed the freeze problem before it got to the users.

gdf:"Everytime there is a change, there are problems" .. "you'll have to wait 10 days as I am leaving for a 10 days conference tour to USA."
then you would agree with me that you made a big mistake because you didn't plan ahead.. releasing the tasks only when you have free time for the problems that come with this.

gdf, can you give us some statistics or a link that shows the number of users that were running gpugrid in an hour from when the new tasks were released? then we could see a drop and how big the impact was.

Andrew3000
Send message
Joined: 1 Feb 10
Posts: 24
Credit: 1,220,848
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwatwat
Message 21484 - Posted: 17 Jun 2011 | 6:25:12 UTC - in response to Message 21481.

it's not like one can just attach a work pc to the project and forget about it from then on.

people invented things like: plug and play, launch and forget(aircraft missiles) etc. because it makes the life of the user easier. i think gpugrid should strive to achieve this too because it also makes less people upset and the number of people that cancel the project will be smaller.

Betting Slip
Send message
Joined: 5 Jan 09
Posts: 589
Credit: 2,039,148,450
RAC: 1,508,450
Level
Phe
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21486 - Posted: 17 Jun 2011 | 7:08:17 UTC - in response to Message 21484.

it's not like one can just attach a work pc to the project and forget about it from then on.

people invented things like: plug and play, launch and forget(aircraft missiles) etc. because it makes the life of the user easier. i think gpugrid should strive to achieve this too because it also makes less people upset and the number of people that cancel the project will be smaller.


We used to call Windows Plug and Play "Plug and Pray"

Basically it's laziness on the part of the public, they wan't wonderful machines that can make their lives easier but don't know, and worse, don't want to know the basics of how that machine works and how to keep it working efficiently. The general public tend to treat a computer like a TV, plug it in and it will do everything itself.

As far as testing goes, they do, but the people who run Beta WU's on GPUGrid are usually dedicated crunchers who have powerful cards and dedicated computers so they wouldn't pick up a problem such as this one.
____________

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1844
Credit: 10,641,103,144
RAC: 9,944,131
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21488 - Posted: 17 Jun 2011 | 8:48:18 UTC - in response to Message 21483.

gdf:"Everytime there is a change, there are problems" .. "you'll have to wait 10 days as I am leaving for a 10 days conference tour to USA."

then you would agree with me that you made a big mistake because you didn't plan ahead.. releasing the tasks only when you have free time for the problems that come with this.

Andrew3000,
This is a forum, not a courtroom. GDF is not the defendant, and you are not the prosecutor. Actually, you and GDF are on the same side, so please, try to be more constructive. Besides, just like every time, there were a discussion, and a beta testing before this release. The problems reported that time, were fixed before the release.

You say:
i know (it is the standard problem with big projects) but what i don't understand is why the tasks aren't tested first in a "private" enviroment (with volunteer users or something) that reflects the complex structure of the public users.

If you understand the problems of big projects you should be a beta tester in the future, this would help the project avoiding this kind of problems next time.

gdf, can you give us some statistics or a link that shows the number of users that were running gpugrid in an hour from when the new tasks were released? then we could see a drop and how big the impact was.

Boinc statistics are available in a couple of webpages. For example on this one. I don't see any significant drop in the number of active users, and in the number of active hosts.

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21489 - Posted: 17 Jun 2011 | 12:40:37 UTC - in response to Message 21488.
Last modified: 17 Jun 2011 | 13:21:25 UTC

Heterogeneity doesn't mean big project, it means variety in system architectures, and more specifically the range of GPU's. Presently, I see no problems on my GTX470's (these can multi-task at least to some extent) when running GIANNI_KKFREE tasks, but some lag still on TONI_AGG tasks. On GTX200 series cards (and earlier) the lag is still there and very high for TONI_AGG tasks. So the reduced GPU usage, while priority is still raised won't do the trick for older cards and requires lower GPU utilization on the Fermi's. You can manually change the priority in Task Manager for Windows. Anyone with more than one GPU need only do this for tasks running on the GPU supporting their monitor (usually GPU 0).

Richard Haselgrove
Send message
Joined: 11 Jul 09
Posts: 790
Credit: 1,422,925,145
RAC: 1,353,568
Level
Met
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21490 - Posted: 17 Jun 2011 | 13:11:20 UTC - in response to Message 21488.

gdf, can you give us some statistics or a link that shows the number of users that were running gpugrid in an hour from when the new tasks were released? then we could see a drop and how big the impact was.

Boinc statistics are available in a couple of webpages. For example on this one. I don't see any significant drop in the number of active users, and in the number of active hosts.

The usual definition of 'active user' on the external stats sites is "earned credit within the last 30 days" (or 60 days, or some measure like that). This change is too recent to show up in a measure like that: only GDF, or somebody else on the project team with authority to run SQL queries on the database, would be able to speak with certainty at this stage.

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21491 - Posted: 17 Jun 2011 | 13:35:17 UTC - in response to Message 21490.

The credit would have dropped anyway, irrespective of whether or not people left; the GIANNI_KKFREE tasks originally did not grant the correct amount of credit. This has now been fixed. Mind you after the fix these GIANNI_KKFREE task ran with lower GPU utilization, so credit might still be slightly down. On the other hand the TONI_AGG tasks are running at higher utilization, so that might go some way to offsetting the reduced utilization of the GIANNI tasks. Whatever the case application changes usually change things and the daily return stats will take a while to balance out as people make adjustments.

In the short run (a week or two) GDF will reset the application to run at Below Normal priority, and in the long run they will update the server to facilitate options for such settings (user choice).

I doubt that the research team even do such SQL queries on their own database; well at least not regularly. It not just the effort of putting this together and maintaining it, you have to constantly monitor the data for it to be of any use.

Andrew3000
Send message
Joined: 1 Feb 10
Posts: 24
Credit: 1,220,848
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwatwat
Message 21492 - Posted: 17 Jun 2011 | 17:01:07 UTC - in response to Message 21489.
Last modified: 17 Jun 2011 | 17:32:54 UTC

"Heterogeneity doesn't mean big project"
"GDF is not the defendant, and you are not the prosecutor."
you both are right. i never said these things.

"Actually, you and GDF are on the same side"
sorry if i don't identify myself.. on my domain if i let a freeze problem get to the end user and tell my client "you'll have to wait 10 days because i must go somewhere" the client fires me and gets a coder that fixes the problem in one day. i also ask myself while coding "do i need to put this in a tab somewhere or should i put it in the main form so that the user isn't made to jump through loops to get to this button?"

"you should be a beta tester in the future"
i already was one when the bug came out.. and i will be one in the future too.

i'm not getting personal or emotional in the dialog on this forum.
my personal interest is for the users to benefit of a very good user experience.

"I don't see any significant drop in the number of active users, and in the number of active hosts."
yes. you are right. there is no sudden drop yet. thanks for the graphs. we'll have to watch them in the future.

but that page has shown me an even bigger problem concerning the last 2 graphs:
http://boinc.netsoft-online.com/e107_plugins/boinc/bp.php?project=52






question for GDF: why in the last 3 months gpugrid had about 1400 new hosts (i presume they joined in order to stay) and instead of having an increase of about 1000 users in the active hosts the graph it shows a decrease of 500 active hosts? is there something going horribly wrong and people are leaving? or am i missing something?

also why out of 22.600 hosts ONLY 3804 meaning 17% are active?

Profile Carlesa25
Avatar
Send message
Joined: 13 Nov 10
Posts: 324
Credit: 72,394,453
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21493 - Posted: 17 Jun 2011 | 18:13:48 UTC - in response to Message 21492.
Last modified: 17 Jun 2011 | 18:23:58 UTC

.
question for GDF: why in the last 3 months gpugrid had about 1400 new hosts (i presume they joined in order to stay) and instead of having an increase of about 1000 users in the active hosts the graph it shows a decrease of 500 active hosts? is there something going horribly wrong and people are leaving? or am i missing something?

also why out of 22.600 hosts ONLY 3804 meaning 17% are active?


Hi, The truth of the numbers of active users think it looks better: http://es.boincstats.com/stats/user_stats.php?pr=ps3grid&st=0 and the reality is that this project, like everyone, is actually supported by very few users.

GPUGRID has 12,532 registered users, the numbers are:

1380 with 60,000 credit in the last month.
1050 with 20,000 credit in the last week.

It does not take an expert in statistical analysis to see GPUGRID are actually about 1,200 users = 10%. Greetings.

Dagorath
Send message
Joined: 16 Mar 11
Posts: 509
Credit: 179,005,236
RAC: 0
Level
Ile
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21494 - Posted: 17 Jun 2011 | 21:13:48 UTC - in response to Message 21492.
Last modified: 17 Jun 2011 | 21:17:48 UTC

"Actually, you and GDF are on the same side"
sorry if i don't identify myself.. on my domain if i let a freeze problem get to the end user and tell my client "you'll have to wait 10 days because i must go somewhere" the client fires me and gets a coder that fixes the problem in one day.


That's what the business world is like. This isn't a business venture. We are just volunteers so we cut the admins/devs a litle slack. We try to show tolerance and patience. Remember the team members are faculty at a university so they have lectures, grading exams/papers, faculty meetings and other duties that eat up their time too. You go too far when you guestion GDF's timing on the release of 6.14. Pull in your horns and back off.

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21495 - Posted: 17 Jun 2011 | 22:26:24 UTC - in response to Message 21494.

I would like to think we are all on the same side, and just discussing logistics.

WRT the charts, the Host Count is just the total number of computer systems attached to the project. This is always going to rise and fairly steadily too; new crunchers come and go, and those that stay replace systems.
Over the last 100days the active host count was steadily droping for around 60days, but then started to level out; in the last 40days listed it only droped by around 100 systems. This might be explained by the arival of the GTX590, a dual GPU, the much predicted loss of lesser GPU’s, and a relative increase in the number of dual GPU systems.
The active user accounts match the active host count fairly accurately. The sharp decline in credit over the last 2 or 3 days was already explained by a mismatch in credit for some long task types, and the new app. It will take a while for things to equilibreate again. Such events are not overly frequent, once every several months.

Snow Crash
Send message
Joined: 4 Apr 09
Posts: 450
Credit: 539,316,349
RAC: 0
Level
Lys
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21497 - Posted: 18 Jun 2011 | 12:27:02 UTC

This new application mainly present changes in terms of the science.

Thanks for the great news. I am always impressed by team GPUGrid's active approach to refining and improving the applications they have created to obtain better / more accurate results in advancing the science they are persuing !!!
____________
Thanks - Steve

Andrew3000
Send message
Joined: 1 Feb 10
Posts: 24
Credit: 1,220,848
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwatwat
Message 21526 - Posted: 19 Jun 2011 | 20:44:46 UTC - in response to Message 21497.
Last modified: 19 Jun 2011 | 21:07:02 UTC

Dagorath:" This isn't a business venture."
oh.. right.. then it's ok to realease versions that freeze the computer of users and force them to shut down the project. i understand.

" You go too far when you guestion GDF"
well.. at least you can move your mouse to navigate this forum.. but when your computer completly freezes (when i was able to move the mouse boinc wouldn't open.. at first i didn't even know what was going on..if i wouldn't have known how to shut it down from task manager i would have been forced to restart the computer and when i would have entered windows it would have been frozen again because boinc starts immediately)
.. then you might think that you have the right to ask a lot of "guestions" to the person that allowed this severe bug to leak beyond the testing team.

"I would like to think we are all on the same side, and just discussing logistics."
same side of the gpugrid project... yes.

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21527 - Posted: 19 Jun 2011 | 22:37:19 UTC - in response to Message 21526.

Voice your concerns guys but keep it friendly, we share the problems and the tasks. There was no intention to cause problems, but each new application does change things, sometimes unexpectedly so. The remaining problems will be rectified in due course.

May I suggest that if your system is unacceptably unresponsive that you configure Boinc to not use the GPU while you are using the system.

In the future we hope to see advancements in Boinc that allow more configuration choices, especially those that better cater for GPU projects.

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1895
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21586 - Posted: 4 Jul 2011 | 10:24:33 UTC - in response to Message 21417.

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



Is anybody aware at what thread priority E@H is working?

gdf

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21587 - Posted: 4 Jul 2011 | 11:19:12 UTC - in response to Message 21586.

E@H is running at Below Normal
MW is running at Normal (but is still laggy on my HD 5850)

I suggest you Beta test using Normal Priority and get opinions, and go back to Below Normal if you have to.

Would it be feasible to use the existing/normal priority on long tasks and Below Normal on Short tasks; that way users could configure their systems to crunch short tasks if their system is too laggy for their needs.
That said people can already select to not run GPU apps when they are using the system via Boinc Manager.

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1895
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21589 - Posted: 4 Jul 2011 | 11:58:36 UTC - in response to Message 21587.

E@H is running at Below Normal
MW is running at Normal (but is still laggy on my HD 5850)

I suggest you Beta test using Normal Priority and get opinions, and go back to Below Normal if you have to.

Would it be feasible to use the existing/normal priority on long tasks and Below Normal on Short tasks; that way users could configure their systems to crunch short tasks if their system is too laggy for their needs.
That said people can already select to not run GPU apps when they are using the system via Boinc Manager.



I am interested in Thread priority, not process priority.

gdf

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21592 - Posted: 4 Jul 2011 | 15:32:57 UTC - in response to Message 21589.
Last modified: 4 Jul 2011 | 17:39:52 UTC

OK, Thread Priority:

Einstein is presently using a Base Priority of 6.
The Dynamic priority varies, from 6 up to at least 10.

Einstein's present CPU usage is around 5%
GPU usage when running Einstein is presently around 67% on my GTX470 (with 6 CPU threads in use). It rises to 73% when no CPU's are in use (perhaps not a good sign). That said, I think tasks ran at around 47% a few weeks ago.

I see today's Beta is the same; Base Priority 6.
From Windows Task Manager Process Priority is Below Normal.
Still seeing 98% GPU Utilization for the task (on a GTX470, SWAN_SYNC on, no CPU crunching).
When crunching with 6 CPU threads, GPU utilization remained high; 97%. When starting CPU tasks there was a few spikes in the graph indicating brief periods of idleness when waiting for the CPU, but these reduced quickly (as the CPU projects loaded). CPU usage 88%.
When running 7 CPU tasks the GPU utilization stayed the same 97%. CPU usage rises to 100%
When trying to run 8 CPU tasks the GPU utilization stayed at 97% but occasionally dropped to about 93%. On average it was probably around 96%.
The CPU tasks of course were not able to use a full core each. What happened was that 2 or 3 CPU tasks only managed between 6 and 9% of the CPU (12.5% being one thread; i7-2600K).
I have experienced no lag when using the system under any of these conditions.

Going to turn SWAN_SYNC off and reboot to see what the difference is...

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21594 - Posted: 4 Jul 2011 | 18:16:17 UTC - in response to Message 21592.
Last modified: 4 Jul 2011 | 18:35:28 UTC

Same Beta Task but with SWAN_SYNC not in use:

8 CPU tasks running: GPU Utilization = 97%
7 CPU tasks running: GPU Utilization = 96%
6 CPU tasks running: GPU Utilization = 96%
0 CPU tasks running: GPU Utilization = 92%

It would seem that without SWAN_SYNC in use it is actually better to use all the CPU's; There is a clear 5% reduction in GPU utilization if you don't use the CPU to crunch any CPU tasks.
Why? The core drops it's frequency (3.6GHz down to 1.7GHz).

Different CPU's will behave differently when being utilized to different extents.
Some CPU's will remain fixed but many will downclock.

If this was your objective, it seems to be working, at least on this one system.
It seems better than the present long tasks that have Base Priority at 10, and yet GPU utilization with SWAN_SYNC off is only 85% (8 CPU threads in use).
On average the beta only used about 2% of the CPU, or 16% of one thread, with no SWAN_SYNC.
What about overall task performance compared to other apps?

Profile GDF
Volunteer moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Send message
Joined: 14 Mar 07
Posts: 1895
Credit: 629,356
RAC: 0
Level
Gly
Scientific publications
watwatwatwatwat
Message 21596 - Posted: 4 Jul 2011 | 20:44:30 UTC - in response to Message 21594.

It seems quite good.

gdf

Profile Retvari Zoltan
Avatar
Send message
Joined: 20 Jan 09
Posts: 1844
Credit: 10,641,103,144
RAC: 9,944,131
Level
Trp
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21616 - Posted: 5 Jul 2011 | 22:34:17 UTC - in response to Message 21594.

Same Beta Task but with SWAN_SYNC not in use:

8 CPU tasks running: GPU Utilization = 97%
7 CPU tasks running: GPU Utilization = 96%
6 CPU tasks running: GPU Utilization = 96%
0 CPU tasks running: GPU Utilization = 92%

It would seem that without SWAN_SYNC in use it is actually better to use all the CPU's; There is a clear 5% reduction in GPU utilization if you don't use the CPU to crunch any CPU tasks.

SK,

To obtain a comprehensive view of the recent changes, you should repeat these tests (SWAN_SYNC on and off, while different number of CPU tasks running) on GIANNI_KKFREE workunits, with the new 6.15 app. I guess these are more sensitive to the number of CPU tasks running simultaneously.

Why? The core drops it's frequency (3.6GHz down to 1.7GHz).

You can disable this energy saving feature in the BIOS setup of the MB.

Profile skgiven
Volunteer moderator
Project tester
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,834,518,624
RAC: 292,156
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21617 - Posted: 5 Jul 2011 | 23:39:13 UTC - in response to Message 21616.
Last modified: 6 Jul 2011 | 0:17:28 UTC

I did, on 3 different systems. Basically all is well, fairly similar results, though there was some differnces of minor note.

There is also of course a difference between task types; the GIANNI_KKFREE long tend to be in the 84% to 86% GPU utilization range while the Toni tasks are around 97% (with and without SWAN_SYNC); so you can run without SWAN_SYNC, and use all cores/threads. We would still have to complete many tasks with and without SWAN_SYNC to know for sure (completion times) if it no longer makes a difference.

GDF, I think you did something to your tasks before going to the USA to reduce their utilization. You might want to consider reversing that.

---
6.15 GIANNI_KKFREE task running with SWAN_SYNC OFF:
(Task Priority Below Normal, Thread Base Priority 6, Dynamic 6, task CPU usage 2.5%)
All 8 CPU threads in use – 84% GPU Utilization.
7 CPU threads in use – 84% GPU Utilization (CPU use at 90%)
4 CPU threads in use – 86% GPU Utilization
No CPU cores in use – 87% GPU Utilization

6.15 GIANNI_KKFREE task running with SWAN_SYNC ON:
(Task Priority Below Normal, Thread Base Priority 6, Dynamic 6, task CPU usage 12.5%)
All 8 CPU threads in use – 84% GPU Utilization.
7 CPU threads in use – 85% GPU Utilization (CPU use at 90%)
4 CPU threads in use – 86% GPU Utilization
No CPU cores in use – 91% GPU Utilization

The Toni task was similar but 97 to 98% GPU Utilization (both on GTX 470 cards).
My GTX260 ran a Toni task at 88% Utilization on W7.

Post to thread

Message boards : News : New application acemdlong 6.14 is out