Seti@Home optimized science apps and information
Optimized Seti@Home apps => Discussion Forum => Topic started by: Raistmer on 16 Jan 2012, 05:54:13 am
-
(http://img841.imageshack.us/img841/5691/mbchii.th.png) (http://imageshack.us/photo/my-images/841/mbchii.png/)
Host config:
Q9450+ATi HD6950
OS: Vista x86
As one can see, new 12.1 driver has definitive speed increase over old 11.2 I used before.
Minimal completion times are better now. From other side, comparison of 11.2 with and w/o -hp switch shows that this switch can give big difference in performance. Currently I collect data to see if -hp will improve elapsed times on 12.1 too.
And it's clearly visible, also, that for this host used AKv8b2 (SSSE3x, x86 one) has lower performance on VLARs than old AKv8b one (SSSE3x, x86 too).
Difference (look for green dots) not too big but definitely exceeds error range.
EDIT: performance difference shows that bugfix (that required more computations to be done) really works so we could detect WoW signal in those missed before parts too now ;D
-
Are you running MB on the 6950?
I'm running 2x6970 and still have the problem with sluggish system when running MB on 6970. If only running AP on 6970, system is 100% responsive.
-
Just increase period_iterations_num to 20.
This should work.
Mike
-
What's the highest value of the setting?
I have used 10 before, but did not experience any notable change (but that was also with a different driver than current 12.1). With 20 now it did improve quite a bit, actually - so thanks for your suggestion.
That said - there has been an ongoing issue with systems running 2x6900 series and I thought Raistmer also reported to AMD, but I'm not sure with post it was.
-
You can try till 100 without any problem.
But somewhere it gets slower of course.
I had a few peops at beta with a 6x card but 20 always worked.
So i do wonder a bit.
But you can try 30 or 40 as well.
Mikie
-
Seems I was in a VLAR dry spot when I tested. The setting does not change the behavior during VLARs.
-
Seems I was in a VLAR dry spot when I tested. The setting does not change the behavior during VLARs.
Then you need to go higher.
-
Seems I was in a VLAR dry spot when I tested. The setting does not change the behavior during VLARs.
Then you need to go higher.
Just like my Nvidia GTX9800+, it will run the VHARs and Normal AR Wu's with 10, but needs 50 for VLARs otherwise it gets a driver restart
Claggy
-
I never get driver restarts only lagging, especially when editing photos and using Windows taskbar, but also simple tasks like writing, I must wait for cursor to go to end of line or characters being written at same speed as my input - selecting menu items is also a waiting game.
Setting is at 60, and zero change. Same with value 100, so the question is how high this value can be set and still be expected to do its job.
-
Do you use -hp switch ?
-
The CPU utilization is exceptionally low for boinc.exe and all ATI MB tasks - extremely stable. the -hp switch does not change the problem with lags/non-responsive GUI.
Overall CPU utilization rarely hits 100%, BTW.
I recall you opened a call at AMD regarding this and dual HD 6900 systems experiencing this - do you remember?
-
I mentioned tha issue on AMD forums. But as I has no such system I can't provide any test cases to file it as bug...
Abouit -hp switch - I asked because it can cause lags itself. With -hp switch there can be ~20s lag at start of each new VLAR.
-
You have so many issues at AMD, so I gave up finding the old issue.
Since AMD has sorted out the overutilization of CPU it's perhaps time to take up this issue again?
Let me know what you need from my system and I will of course provide it :-)
Perhaps this has a renewed interest with the release of HD 7900?
-
Please describe you problem once more (as you experience it with 12.1 drivers).
Maybe even better if you will post directly on AMD forum...
-
I've opened this thread:
http://forums.amd.com/devforum/messageview.cfm?catid=390&threadid=158457&enterthread=y
-
Ah... I thought you reference to your old problem with inabality to use all cores in multicore/multiGPU config....
Post you made on AMD hardly will be answered there, it's too app specific...
This lags we should try to solve here....
What I need is the csv file from Profiler running MB with VLAR task. COuld you provide it?
-
I don't have Visual Studio so I'm stuck with command line which I'm not getting.
According to documentation example to collect performance counter for gpu:
sprofile -o "/path/to/output.csv" -w "/path/to/app/working/directory" "/path/to/app.exe" "--device gpu"
If I enter
sprofile.exe -o D:\Data\S@HMBOCL.CSV "D:\ProgramData\BOINC\projects\setiathome.berkeley.edu\MB_6.10_win_x86_SSE3_OpenCL_ATi_r331.exe"
I will get no perfdata, as the MB application does not run directly from cmd. If I call boinc.exe, I cannot also call MB app, as boinc will use app_info to start GPU app.
So what is the full commandline to collect perfdata for MB openCL?
-
sprofile <app_name> wold be enough. But don't forget to run it from folder with MB's input data.
-
The problem is that running MB_6.10_win_x86_SSE3_OpenCL_ATi_r331.exe directly from cmd it will terminate immediately / not commence feeding GPU, and running it when boinc.exe is running it will also terminate due to all GPUs allready chrunching max tasks based on app_info.
-
Lets start another thread for this.