Forum > GPU crunching
Modified SETI MB CUDA + opt AP package for full GPU utilization
Maik:
btw.
I was testing the v5 400basic mod on a VLAR: 0.0112
No crash, laggy like hell and it took 25min to do 1%.Ii aborted it.
I think my card is still to slow for VLARs so i'll try the v5a. thanks for this ;)
Maik:
--- Quote from: Raistmer on 12 Jan 2009, 08:54:47 pm ---Current bug fixes fight mostly with different overflows. Actually, they should eliminate overflows at all. So, please, report any overflow you will get if it not from VLAR and not from task was ran after driver crash w/o OS reboot.
--- End quote ---
* 16no08ab.25078.13571.14.8.1_1
* WU true angle range is : 2.579270
* SETI@Home Informational message -9 result_overflow
* Spike count: 30
* wingman: in progress
* 16no08ab.25078.13571.14.8.0_0
* WU true angle range is : 2.579270
* SETI@Home Informational message -9 result_overflow
* Spike count: 27
Pulse count: 2
Triplet count: 1
* wingman: CPU - same resultv5a, driver 8120, no driver crash, next wu's in list running fine
Edit: 2 more -9 overflow ... did reboot ... next overflow ... the 3new ones all with Spike count: 30
still have 11 more wu's form this series in task list, lets see ...
summary 5 wu's now, all with AR: 2.579270, all from 16no08ab.25078.13571.14.8.x_x ... -series
it seems that this series picked up the iss or something like that ;)
all wingmans who returned results yet have same results ...
[attachment deleted by admin]
Raistmer:
Ok, I formulated it bad.
Rephrase: All CUDA MB overflows that didn't pass validation versus CPU wingman - because there is "usual" overflows and "non-usual" ones.
Surely we take interest only for "non-usual" ones for this moment.
Archangel999:
use the new app and work better then the 396 but are more lagy but it crunch realy fast i 'm having 8800gtx and use the new vbscript all working fine
Raistmer:
There is known "feature" of BOINC 6.4.5 that now works more as bug - it sets process priority for CUDA application to "Normal" instead of "Idle"
It helps nothing because "Idle" priority of worker thread has the same value for "Normal" and "Idle" priorities of process (so called priority class) so thread priority should be adjusted, not process priority (not priority class). Setting process priority to "Normal" excessively increase control thread priority that caused sluggish OS behavior.
So for Don's (Geek@Play) request I did another cleanup for BOINC - now modded CUDA MB will adjust priority class as well. Hope it will give more smooth execution.
V5b attached.
[attachment deleted by admin]
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version