The changes will be mostly on usability for GPUGRID users. Planned changes (we cannot guarantee to have them all, but we will try):

1) Project preference for running the app at higher priority than normal (higher speed)

2) Project preference for using 1 core to control the GPU (equivalent to current SWAN_SYNC=0)

3) Having two applications, acemd_long and acemd. acemd_long will have longer workunits, you can opt out of it in project preferences. Longer WUs will give relatively more credits per hour.

4) All new WU will be shipped with the same options of the current DHFR1000, so they will be generally faster.

5) Higher GPU usage in general (closer to 99%)

Planned release in mid February.

GDF

That sounds really nice - thumbs up!

MrS
____________
Scanning for our furry friends since Jan 2002

The changes will be mostly on usability for GPUGRID users. Planned changes (we cannot guarantee to have them all, but we will try):

No. we will stay to cuda3.1.

gdf

Points 3),4),5) are now ready to go.

gdf

I guess they will start feeding them into the system when they make them. I completed an et today, so I expect they have tested to the extent that they are setup correctly and ready to go with large tasks.

It's worth noting that the present adc5-IBUCH tasks take almost twice as long as the KASHIF_HIVPR and more than twice as long as the GIANNI_DHFR1000 tasks, so I expect when new tasks are produced they will include the new and faster routines.

I have already set my GTX470's to accept long tasks, and set my GT240's to only pick up short tasks, so when the long tasks are released I won't have to do anything.

In Your account, under GPUGRID preferences create two (or up to 4) profiles (default, home, work and school). Set one to crunch short tasks and the other to crunch long tasks. Add each of your systems to one of the profiles. You can do that by going to Your computers, clicking Details and changing from default.

It has not yet been announced that there are short and long tasks.

Performance changes with different tasks, but this should generally improve soon*.

All CC2.1 cards, including the GTX460, have a somewhat incomplete ability at GPUGrid due to shader access problems, mostly down to the ACEMD application, I think. This is why I advise people to get CC2.0 cards if possible. Perhaps the remaining third of the shaders will be usable in a future ACEMD edition. It would be a very nice boost to the project.

It’s down to the project managers to say what is urgent for GPUGrid (an ATI app, new faster routines*, long tasks, server or website maintenance, support, presentations, publications...), and they can’t do much in some areas (tools and drivers) other than wait. Unfortunately this is the situation with CC2.1 cards.

All we crunchers can do is report problems, make suggestions and optimize our systems as best we can; using swan_sync=0, freeing up a CPU core for every GPU, configuring your preferences, reporting tasks immediately and using a fast operating system - due to the WDM overhead Vista and Win7 are slower than XP and Linux, though this may not be apparent from looking at GPU Utilization, but rather through task performance.


Good luck,

Did anybody of you tested if with higher priority was still beneficial to assign a full cpu core to the application (SWAN_SYNC)?

Are there any collateral effects in increasing the priority to high-priority (like slow response of the desktop)?

thanks,
gdf

Kirby54925, set your CPU usage to 75%. You have a GTX570, it needs to be able to use some of the CPU. If you let Rosetta hog all the CPU cores you will knobble the GTX570 performance. I would expect the difference between CPU Time and RunTime to also drop somewhat for your Rosetta tasks, so you would not quite be losing a full CPU core anyway.

GDF, I pushed the Priority to High on all four GT240's in the one system when not using swan_sync. It only increased GPU Utilizaion on one GPU by about 4% - none of the others changed. No problems with the system (also running CPU tasks at the time). I have not tried it when swan_sync is being used, but I see little point. Tasks were running between 65% and 90% utilization. The increase from using swan_sync now appears to be less than 10% for GT240’s running the 6.12app on Vista x64, while running CPU tasks.

So, we can focus on SWAN_SYNC alone and let people use it via project preferences?

gdf

A preference for swan_sync would be useful, especially if you could do it for Linux.

It is already possible to reduce the number of CPU cores to use (for CPU projects) from Computing preferences (and Boinc Manager):
On multiprocessors, use at most - 100.0 % of the processors.

ok

In the future most of the tasks will reach 96-98% load.

gdf

another odd thing is that if i overclock from 650mhz to 850mhz the gtx 460 768mb when the game has 60%gpu the fps does not increase.

There is none and this is a problem for the project.
The GT440 would perform no better than a GT240. Stay away from the GT430 and below (if you can); as far as I know these are cc2.1. Ditto for the GTS450, GTX460 and GTX560.
There is a very big gap between the GT240 and the GTX465 (the lowest powered CC2.0 Feri). The only CC2.0 cards are the GTX 465, 470, 570 and 580. These are all 200W+

I am fairly sure the CC2.1 problem is here for the immediate to midterm future (0-6 months); I don’t know of any mid-range CC2.0 cards being developed and software changes take a long time and may never resolve the situation. Beyond 6 months there are some possible changes (program/kernel or app) that might improve CC2.1 performance but there is no guarantee. It would be wrong to get a GPU thinking that improvement is just around the corner.

It should have been fixed now by Toni.

gdf

Tony’s long tasks seem to be running well and giving plenty of credit :) On my GTX470’s they complete in under 8h (XP x86, i7-920).

Run time 29089, Claimed credit 27186.875, Granted credit 40780.3125 task
Expected (24/7) daily credit from one (ref/stock) GTX470 = (86400/29089)*40780=120120

Compare that to this different Tony task, on the same GTX470:
Run time 10254, Granted credit 9283
Expected daily credit from one GTX470 = (86400/10254)*9283=78218

Just over 50% more credit.

Their popularity seems to have risen sharply since yesterday; 200 in progress when I checked. Now there are over 1000 in progress, about 1/3 of the tasks.

I am still tuning the acemdlong tasks, se we don't have a steady supply of them yet (there will be soon). Glad to see that they worked well. :-)

the higher credits should compensate for the fact that the probability to fail is higher due to longer running time.
If you have a stable machine, then it's all good.

gdf

Long run tasks run on the 6.13app (cuda31). They should work for Fermi cards and CC1.3 cards such as a GTX295. I expect they are least likely to fail on the top Fermi cards.

For now, I would suggest you chose to only run the normal tasks on your GTX295 system and you might want to restart it. This might be a temporary issue so try again in a week or so.

Good luck,

Utilization will increase in new jobs, this was an old one made longer as we needed further results.

gdf

We are introducing the possibility for users to select between shorter (acemd2, approx 4 hours on GTX275 cards) and longer (acemdlong, 8 to 12 hours on GTX480) tasks. Simply go to your account preference to select which applications you want to crunch for. Long task are of course credited higher, but GPUs with less cores cannot simply compute them in time. 31 Jan 2011

We have released internally guidelines for short and long runs. Most likely a factor 2 difference is unavoidable between different workunits in the same queue.

gdf

Hi Fred, I thought these KASHIF_HIVPR_wo tasks were quite long too.

I see you missed out on the full credit bonus. Perhaps lowering your cache would help, and/or man-managing which projects you run on a day-day or week-week basis.

Not using swan_sync would explain some of the slowness (16.6% slower). On such a powerful card using swan_sync & freeing a CPU core becomes more important.

While your GPU is clocked at 1.4GHz the other card clocks in at 1.45GHz. That said, you might have a faster CPU and are using 64bit XP.

It also looks like your task also restarted about 5 times. Each time can lose up to 5min. Changing your processor usage, Switch between applications everyto a high number such as 999 should prevent this, or using Leave Applications in Memory (LAIM), if you don't already have it selected.

Your task run, 18,302.34 1,226.58 10,347.84 12,934.80 ACEMD2: GPU molecular dynamics v6.13 (cuda31)
Other cruncher, 15,688.01 15,616.50 10,347.84 15,521.76 ACEMD2: GPU molecular dynamics v6.13 (cuda31)

The task on two systems

So, we would like to update the applications to the newest version.
1) Some little speed improvement
2) Only cuda3.1 version
3) Some bug fixes
4) If we can the read of SWAN_SYNC as a boinc parameter.

g

We will add cuda4 app when ready of course. Always keeping only two versions.
gdf