Where have you found tasks run on a different GTX 560 ...

GTX 560 Ti was notorious to produce false signals (wrong computations) because of too high clock and/or too low voltage (as set by default in the video card factory).
I don't know if that is the same/similar for GTX 560

Your GPU seems to run at "Max clock frequency: 1660Mhz" (this is "shader/CUDA Cores" clock):
http://setiathome.berkeley.edu/result.php?resultid=5104724560

... which looks within spec:
http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-560/specifications
http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-560ti/specifications

But nevertheless you can try (for test) to (temporarily) Underclock the GPU and video memory and/or raise the voltage a little to see if that eliminates/decreases # of "Validation inconclusive"/"Invalid".

e.g. by MSI Afterburner
https://gaming.msi.com/features/afterburner
https://www.guru3d.com/files-details/afterburner-download-msi.html
http://www.majorgeeks.com/files/details/msi_afterburner.html

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

Or are you implying that some of the tasks the validator marks as valid are in fact invalid, but still deleted 24 hours later since they were marked valid?

When workunit validates all results (including invalids ones and computation errored ones) purged from BOINC database. Usually it happens after 24h from validation. Sometimes task can hand for much longer times but it's issue with BOINC backend in Berkeley, not rule of thumb.

Since MOST of the tasks are purged that fast, not enough are left for a proper determination of just how many r3500 tasks were invalid on my GTX 560, so I don't see any point in continuing the discussion of exactly how many there were.

I don't have enough free time to inspect my list of tasks every 24 hours, so I usually don't. This means I don't necessarily see all the tasks marked as invalid.

I'll try to do a little tuning once a week, but I don't have enough free time to do it every week.

Where have you found tasks run on a different GTX 560 ...

GTX 560 Ti was notorious to produce false signals (wrong computations) because of too high clock and/or too low voltage (as set by default in the video card factory).
I don't know if that is the same/similar for GTX 560

Your GPU seems to run at "Max clock frequency: 1660Mhz" (this is "shader/CUDA Cores" clock):
http://setiathome.berkeley.edu/result.php?resultid=5104724560

... which looks within spec:
http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-560/specifications
http://www.geforce.com/hardware/desktop-gpus/geforce-gtx-560ti/specifications

But nevertheless you can try (for test) to (temporarily) Underclock the GPU and video memory and/or raise the voltage a little to see if that eliminates/decreases # of "Validation inconclusive"/"Invalid".

e.g. by MSI Afterburner
https://gaming.msi.com/features/afterburner
https://www.guru3d.com/files-details/afterburner-download-msi.html
http://www.majorgeeks.com/files/details/msi_afterburner.html

I've never changed those settings from what was set at the factory.

I'll add those suggestions to my list of thing to try when I have time, but I don't expect to find time to try more than one change a week.

And how can you tell that they're a problem with the card instead of a problem with the way r3500 handles a GTX 560?

Try to find hosts with other GTX560 running OpenCL NV MB. And preferably - on beta (cause there results last longer). How they behave?
Did you use some tuning other than proposed in ReadMe? What tuning line?

I'll let you look for those other hosts - I don't have enough free time to do it.

No tuning at all so far.

Or are you implying that some of the tasks the validator marks as valid are in fact invalid, but still deleted 24 hours later since they were marked valid?

When workunit validates all results (including invalids ones and computation errored ones) purged from BOINC database. Usually it happens after 24h from validation. Sometimes task can hand for much longer times but it's issue with BOINC backend in Berkeley, not rule of thumb.

Since MOST of the tasks are purged that fast, not enough are left for a proper determination of just how many r3500 tasks were invalid on my GTX 560, so I don't see any point in continuing the discussion of exactly how many there were.

I don't have enough free time to inspect my list of tasks every 24 hours, so I usually don't. This means I don't necessarily see all the tasks marked as invalid.

I'll try to do a little tuning once a week, but I don't have enough free time to do it every week.

That's why testing better to conduct on SETI beta.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Or are you implying that some of the tasks the validator marks as valid are in fact invalid, but still deleted 24 hours later since they were marked valid?

When workunit validates all results (including invalids ones and computation errored ones) purged from BOINC database. Usually it happens after 24h from validation. Sometimes task can hand for much longer times but it's issue with BOINC backend in Berkeley, not rule of thumb.

Since MOST of the tasks are purged that fast, not enough are left for a proper determination of just how many r3500 tasks were invalid on my GTX 560, so I don't see any point in continuing the discussion of exactly how many there were.

I don't have enough free time to inspect my list of tasks every 24 hours, so I usually don't. This means I don't necessarily see all the tasks marked as invalid.

I'll try to do a little tuning once a week, but I don't have enough free time to do it every week.

That's why testing better to conduct on SETI beta.

I've never seen SETI beta.

[snip]

It is the 560.
First 3 turned out to be invalid and all are Guppies.
Those names starting with blc.
The 440 processes them just fine.
Do you have one CPU core freed ?

Add to the comand line text file

-sbs 192 -no_defaults_scaling

I finally have a little free time and will try to install this change tonight.

If I'm able to do so, I'll enable tasks for a few more days.

One core shared between GPU tasks and work from the console, so PARTLY freed.

Or are you implying that some of the tasks the validator marks as valid are in fact invalid, but still deleted 24 hours later since they were marked valid?

When workunit validates all results (including invalids ones and computation errored ones) purged from BOINC database. Usually it happens after 24h from validation. Sometimes task can hand for much longer times but it's issue with BOINC backend in Berkeley, not rule of thumb.

Since MOST of the tasks are purged that fast, not enough are left for a proper determination of just how many r3500 tasks were invalid on my GTX 560, so I don't see any point in continuing the discussion of exactly how many there were.

I don't have enough free time to inspect my list of tasks every 24 hours, so I usually don't. This means I don't necessarily see all the tasks marked as invalid.

I'll try to do a little tuning once a week, but I don't have enough free time to do it every week.

That's why testing better to conduct on SETI beta.

I've never seen SETI beta.

Here is a link to it. You have to register for an account as it is separate from the main project

. . Hi Raistmer,

. . Now that WOW has finished I have taken the bit and done an install of Lunatics Beta(4) selecting SoG r3500 for the GPU.

. . As usual the install went without a hitch and SoG in happily crunching the tasks still identified as CUDA50.

. . The command line file remains default (ie empty) yet while there is no SoG section in app_config.xml it appears to have followed the settings in the CUDA50 section of that file as it is running 2 WUs on the GPU.

. . This affords a ready comparison of the two at the same level. SoG is achieving slightly higher GPU utilisation (up from around 90% to over 95%) and a corresponding increase in GPU temp of about 5 degrees. But there must be an inherent processing advantage with CUDA50 as the run times for normal AR Arecibo work has increased by about 25% (on a sample base of 10/12 tasks). I have now queued an equal number of guppi tasks to see how they fair. Under CUDA50 normAR Arecibo tasks were 60 mins +/- 3 mins, under SoG they are 76 mins +/- 3 mins. Guppi tasks were less consistent under CUDA50 taking anywhere from 120 to 150 mins (still runing two WUs) so I am interested to see if that changes significantly and in which direction.

. . You wanted feedback on how r3500 performs on low end NV GPUs. With a CC of 3.5 and CU of only 2 the GT730 (mine has 2GB GDDR5 ram) while high end of low order GPUs is still low order. It is at your disposal for the next week and I will happily try any configuration you wish and report as best I can.

. . If I have no response before hand the next step will be to add a SoG section to app_config.xml and set it for single WU execution then try the command line options you have mentioned in the forum (if I can find the relevant messages again that is).

. . Have fun :)

.
. . [edit] On another note I moved half a dozen Arecibo VLAR tasks into the GPU cache on the i5 (GTX950) and they are running quite well as you expected. FWIW runtimes are considerably longer than guppis (on GPU guppis approx 46 mins VLAR approx 80 mins, on the CPU guppis approx 45 mins and VLAR 70 mins) so unless desperate I think I will still leave Arecibo VLAR work for the CPU. For contrast norm AR Arecibo tasks on CPU run for approx 70 to 80 mins but on GPU about 35 mins.

.


.

But there must be an inherent processing advantage with CUDA50 as the run times for normal AR Arecibo work has increased by about 25% (on a sample base of 10/12 tasks).

When I last checked with pre-FERMI GSO9600 and GTX3260 there was pretty big advantage in FFT performance. Own NV cuFFT performed much better that oclFFT on those GPUs. For later GPU models I did not done such profiling so far (still have only taken for some time from friend GT720, other donated GPUs still have to come). So, SETI MB own code should overcome this CUDA vs OpenCL NV advantage. On pre-FERMI GPUs this was not possible so far so I even started CUDA back-port some time ago just to be able to use cuFFT instead of oclFFT. That project quite abandoned for now due to lack of time.


Try to add -tt 60 to command line and see how GUI lags change if any.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

But there must be an inherent processing advantage with CUDA50 as the run times for normal AR Arecibo work has increased by about 25% (on a sample base of 10/12 tasks).

When I last checked with pre-FERMI GSO9600 and GTX3260 there was pretty big advantage in FFT performance. Own NV cuFFT performed much better that oclFFT on those GPUs. For later GPU models I did not done such profiling so far (still have only taken for some time from friend GT720, other donated GPUs still have to come). So, SETI MB own code should overcome this CUDA vs OpenCL NV advantage. On pre-FERMI GPUs this was not possible so far so I even started CUDA back-port some time ago just to be able to use cuFFT instead of oclFFT. That project quite abandoned for now due to lack of time.


Try to add -tt 60 to command line and see how GUI lags change if any.

. . If I understand correctly I should add the cuFFT command and -tt 60 to the command line. As it is, I am not noticing much lag but I will play with the values for -tt and see where lag becomes noticable. I will look in the docs for information on using cuFFT.

. . It will be interesting.

. . Stephen

cuFFT is own nVidia FFT library available only on CUDA. For OpenCL app I use oclFFT instead.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

cuFFT is own nVidia FFT library available only on CUDA. For OpenCL app I use oclFFT instead.

. . OK got it, use oclFFT. Glad to hear that because I could not find cuFFT in the docs ... :)

Stephen

. . {edit} should I still use -sbs settings or -use_sleep or any other commands as well?

. . {edit} should I still use -sbs settings or -use_sleep or any other commands as well?

As was mentioned already I look for best defaults, not for best tuning for particular host. New default will be -tt 60 -high_prec_timer -use_sleep for NV
and -tt 60 for ATi. That options should be tested.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Has the r3500 testing sucked the supply of Windows GPU workunits dry?

A few minutes ago, neither of my computers had any GPU workunits at all, with only SETI@home enabled. Telling both of them to update SETI@home did nothing, so I decided it was time to enable a different project offering GPU workunits.

I'm now switching to testing the new default for NV. Do I also need to do any testing I skipped?

. . {edit} should I still use -sbs settings or -use_sleep or any other commands as well?

As was mentioned already I look for best defaults, not for best tuning for particular host. New default will be -tt 60 -high_prec_timer -use_sleep for NV
and -tt 60 for ATi. That options should be tested.

. . I added the -tt 60 and this increased the GPU activity but I did not notice any lag or hesitation when typing and such. Runtimes for Arecibo normAR tasks were typically 46 mins (Cuda50 typically 34 to 36 mins). I increased the -tt value to 120, this improved GPU utilisation even further and runtimes down to approx 42 mins but noticing a little hesitation/stickiness on BOINC manager's slider controls, otherwise typing seems mostly unaffected.

. . I will add those commands to the command line to be sure they are running, should I use -use_sleep_ex of 1?

.

Has the r3500 testing sucked the supply of Windows GPU workunits dry?

A few minutes ago, neither of my computers had any GPU workunits at all, with only SETI@home enabled. Telling both of them to update SETI@home did nothing, so I decided it was time to enable a different project offering GPU workunits.

I'm now switching to testing the new default for NV. Do I also need to do any testing I skipped?

. . There were problems with the splitters last week but now WUs seem to be flowing OK. The project has been down for maintenance in the last 12 hours (started approx 9 hours ago not sure when it finished but has been back up for at least 3 hours) so perhaps you were trying during that time.

. . I would give it another try now. It is an often recommended practice to make sure your WU cache is filled before maintenance begins.

. . Stephen

.

Has the r3500 testing sucked the supply of Windows GPU workunits dry?

A few minutes ago, neither of my computers had any GPU workunits at all, with only SETI@home enabled. Telling both of them to update SETI@home did nothing, so I decided it was time to enable a different project offering GPU workunits.

I'm now switching to testing the new default for NV. Do I also need to do any testing I skipped?

. . There were problems with the splitters last week but now WUs seem to be flowing OK. The project has been down for maintenance in the last 12 hours (started approx 9 hours ago not sure when it finished but has been back up for at least 3 hours) so perhaps you were trying during that time.

. . I would give it another try now. It is an often recommended practice to make sure your WU cache is filled before maintenance begins.

. . Stephen

.

Works if you get enough advance notice of the maintenance. I didn't.

One computer automatically got more; the other will take longer to be ready for more.

Works if you get enough advance notice of the maintenance. I didn't.

It happens every week.
It is announced every week on the main page as News.

---

Grant
Darwin NT

. . I will add those commands to the command line to be sure they are running, should I use -use_sleep_ex of 1?

.

-use_sleep has same action as -use_sleep_ex 1

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.