Someone on the BOINC message boards has just pointed out that GPUGRID add an extra line to

<stderr_txt>
...
# Approximate elapsed time for entire WU: 25733.974 s
called boinc_finish
</stderr_txt>

While we're waiting for BOINC to officially record the information and display it on the result pages here, this would be a helpful initiative for SETI to copy.

I have seen this on my gpugrid workunits also. It sure helped me to fine tune the OC functions on my cards.

Someone on the BOINC message boards has just pointed out that GPUGRID add an extra line to

<stderr_txt>
...
# Approximate elapsed time for entire WU: 25733.974 s
called boinc_finish
</stderr_txt>

While we're waiting for BOINC to officially record the information and display it on the result pages here, this would be a helpful initiative for SETI to copy.

That was me. :)

The guys at gpugrid only uses cpu time to query the GPU of its status, all the actual computation happens at the GPU and barely anything runs on the CPU.

In the past the CPU and GPU times were identical at gpugrid, but high credits were still granted based on some GPU flops formula. This created a 100% CPU utilization that was basically wasteful.

Now the CPU time is lower and so is the cpu queries of the gpu.

Like I said on the other board, it wont harm seti to learn a trick or two from gpu grid. And seti can also work with nvidia as gpugrid have a good level of coordination and support with nvidia for code optimization and bug ironing purposes.

This is a beta project, and as with all betas it is expected to be unstable and immature.

I agree, we should implement this.

Even better would be for BOINC to add a concept of "coprocessor time" to the client/app communication.

Eric

---

I agree, we should implement this.

Even better would be for BOINC to add a concept of "coprocessor time" to the client/app communication.

Eric

Eric,

While you're picking up ideas for (relatively quick and easy) improvements, could I draw your attention to Raistmer's 'increased thread priority' idea, released for testing at SETI Main, and described in principle at Lunatics (pre-release area, login required).

I'm afraid I don't have source-code references for the changes required, but it sounds minor and effective.

It's effective indeed. My 9600GSO doing each task ~20min while all four cres busy with einstein@home (no degradation in speed for einstein, net gain for both projects).
And modification really VERY easy to implement.

int seti_analyze (ANALYSIS_STATE& state) {
sah_complex* DataIn = state.savedWUData;
int NumDataPoints = state.npoints;
sah_complex* ChirpedData = NULL;
sah_complex* WorkData = NULL;
float* PowerSpectrum = NULL;
float* tPowerSpectrum; // Transposed power spectra if used.
//R: Added set priority win-API call to allow full usage of GPU in non-idle systems.
#if _WIN32
if(!SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_BELOW_NORMAL)){
DWORD error=GetLastError();
LPSTR lpBuffer;
FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM|FORMAT_MESSAGE_ALLOCATE_BUFFER,NULL,error,0,lpBuffer,0,NULL);

fprintf(stderr,"ERROR:can't set priority: %s\n",lpBuffer);
}
#endif

#ifdef USE_CUDA
.....

That's all! YOu even not need that error handle.
It could be just easy as

#if _WIN32
SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_BELOW_NORMAL);
#endif

---

News about SETI opt app releases: https://twitter.com/Raistmer