As I wrote on Beta, where you asked the same question:

The iGPU restarts because you still have some older versions onboard (SETI@home v8 v8.14 (opencl_intel_gpu_sah). That one is a crappy version for the iGPU.

Abort all SETI@home v8 v8.14 (opencl_intel_gpu_sah), and your iGPU will start running SETI@home v8 v8.15 (opencl_intel_gpu_sah), and SETI@home v8 v8.16 (opencl_intel_gpu_sah)

You might as well abort SETI@home v8 v8.15 (opencl_intel_gpu_sah)too, since SETI@home v8 v8.16 (opencl_intel_gpu_sah) have just been released.

That is for your computer with the INTEL Intel(R) HD Graphics 4400 (1603MB) OpenCL: 1.2. Your other two computers with the Nvidia GPU's, should not be affected by the restarts.

. . HI,

. . Do you have any knowledge/advice on why my rig with the 970s keeps sleeping the video drivers? I was running SoG version r3472 so I went back to r3430 which is running on this machine AOK but it still does it. The drivers just go off into limbo never to return and I have to reboot the machine, it was down most of last night. I have updated to the latest drivers 368.39 and removed anything that seems like it might be hijacking the processors but still not fixed.

. . It is running windows 10 pro, and I cannot say whether that could be part of the problem or not as I upgraded the machine with an SSD, the 970s and windows 10 at the same time.

I set the laptop as gpu because I thought gpu development was in need of more over cpu. I'm running stock as beta has provided, no switches. I'm waiting for instructions on what settings I need to test next. I was just pointing out that I see a lot of restarts on guppi vs no restarts on arecibo.

thanks for participation - look beta thread for instructions regarding 8.16 app testing.
Just check if restarts with 8.16 continue and report again there (on beta forums).

---

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

You have -period_iterations_num=1 in your command line file. That is too low for your 970, especially in that system. Remove that command completely, and let it go default (50) No wonder that your drivers crash and burn.

You have it pretty low even for your 950 (-period_iterations_num=5). Don't play around with those settings, until you have established a good baseline. Remove that command also for the 950.

I have a 980, and I do not go lower than 10 on that setting.

You do not gain many seconds/WU, by lowering the -period_iterations_num below its default (50), but you surely strain the system, enough for the drivers to reset, if you go too low for your particular system (the combination of GPU and CPU, and memory). After all, your 950, is sitting in a system with an old Intel(R) Pentium(R) D CPU 3.00GHz, so it's possible that even the default setting at 50, is too low for that system.

Using the settings in the readme file for the app, really is something one has to do with care, and preferably knowing exactly what one is doing.

Edit, added: Running 2 970s in a system with only a Pentium(R) D CPU 3.00GHz, is really asking for trouble IMO. Especially when running OpenCL SoG, or non SoG even. Maybe CUDA would work better.

. . Hi

. . Thanks for that. I will try higher values, but when I have increased the value of period_iterations_num while trying to optimise this unit the output decreased significantly. I do realise I am asking a lot of the Pent-D, and in retrospect I should just have used a pair of GTX 950s, but the die is cast and I have to try and make the best of these units.

. . The GTX950 is running on the i5 and is purring like a kitten. I am using this machine to access everything and have only moderate lag/twitching which I have learned to live with. I am loathe to change any settings when they are working so well.

. . Both systems have 8GB ram so I don't think that is an issue. Funny thing is that it seems to lock up most when downloading new WUs. But since I have to reset to regain use of the computer it may just be con-incidence that those are the events I have witnessed. After it is locked up I cannot learn much about the cause.

. . Just an update. When I increased period_iterations_num from 1 to 5 Guppi times increased from 44-48 mins to 52-57 mins and still had some video driver lockups. Increasing the value to 10 took Guppi runtime to 59-70 mins and reduced lockups a little bit. I am not going to try higher values or I will need a time machine to see when the WUs complete. Pardon my cynical sense humour.

. . But since this machine, which is running a value of 1, is purring like a kitten and has had NO lockups I do believe there is something else at play. It may be the Windows 10 drivers are incomplete or glitchy. Windows says there is no driver for the SM Bus controller in the Nforce4 SLI chipset, and one other unidentified device(controller). I cannot find Windows 10 drivers anywhere, certainly NOT from Nvidia themselves. So I may have to revert to Windows 7 and reload the correct drivers for that OS, maybe then I can get S@H to run glitch free.

. . There is no doubt that driving 2 GTX970s with a Pentium D is very ambitious, but I am gaining faith that with the right setup it can cope, even if only just.

. . An update on that. Freezing is worse with period_iterations_num set to 10, so I have gone back to 5 and they have stopped, over a 3 day period with 10 I had 5 lockups. In the 4 days since not one touch wood (hand on head).

. . An update on that. Freezing is worse with period_iterations_num set to 10, so I have gone back to 5 and they have stopped, over a 3 day period with 10 I had 5 lockups. In the 4 days since not one touch wood (hand on head).

All these values below default of 50 so entirely on user discretion.
Regarding 10 locks and 5 go - most probably you just see AR variation.

---

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

. . An update on that. Freezing is worse with period_iterations_num set to 10, so I have gone back to 5 and they have stopped, over a 3 day period with 10 I had 5 lockups. In the 4 days since not one touch wood (hand on head).

All these values below default of 50 so entirely on user discretion.
Regarding 10 locks and 5 go - most probably you just see AR variation.

. . I think there is a hardware issue too under Windows 10. I cannot source Windows 10 drivers for the mobos NForce4 SLI chipset. It is running but I think there are timing issues with the drivers and this may be interacting with the apps to cause problems. I am not seeing messages saying "video driver stopped but has restarted" though I did earlier on when first running SoG. Now it just goes into never never land and requires a reboot. But it is far better when set to 5. I cannot explain why but it may be AR related.

Task 5087560129
http://setiathome.berkeley.edu/result.php?resultid=5087560129

SETI@home v8 v8.12 (opencl_nvidia_SoG)
windows_intelx86

Running on a GT 440.

Even after running for five hours, the progress never went past 0.001%.

No checkpoints written, even after five hours.

Estimated time to completion was several years past the deadline, so I aborted it.

I looked over the last month's SETI@Home work for my two computers. Nine tasks were reported as completed, but the only one marked as valid ran on my GTX 560 (with 8.12) and my wingmate also ran Nvidia.

Does this mean that there is a problem in the validator matching work done on Nvidia to work done on a CPU or on any other brand of GPU?

Task 5087560131
http://setiathome.berkeley.edu/result.php?resultid=5087560131

Another task that ran for hours with no checkpoints and no progress beyond 0.001%. Now aborted.

GT440 under Windows 10

SETI@home v8 v8.12 (opencl_nvidia_SoG)
windows_intelx86

Looks like 8.12 needs a few changes:

First, report what GPU was found, and if that one is not suitable, terminate quickly.

Second, set up a timer to check for running much longer than expected with no progress past 0.001%, in which case the CPU portion of the task should report an error and then terminate quickly.

After that, run normally except for the new timer.

From stderr of the failed task:

OpenCL Platform Name: Intel(R) OpenCL
Number of devices: 0


Work Unit Info:
...............
Credit multiplier is : 2.85
WU true angle range is : 0.443385
Low-performance GPU detected, default period_iterations_num set to 500
For low-performance GPU path use_sleep enabled with 5ms per iteration
Used GPU device parameters are:
Number of compute units: 3
Single buffer allocation size: 128MB
Total device global memory: 1536MB
max WG size: 1024
local mem type: Real
FERMI path used: yes
LotOfMem path: yes
LowPerformanceGPU path: yes
period_iterations_num=500

</stderr_txt>
]]>


Number of devices: 0
Rather unexpected, as if it couldn't use the GT 440.

For low-performance GPU path use_sleep enabled with 5ms per iteration
If I'm the one who needs to change this, note that I don't know how to change it.

Number of compute units: 3
Appears to use a definition of computer units very different from what my CUDA class used.

Note that the motherboard of this computer is known as unable to boot with an Nvidia GPU past the Geforce 500 generation. I was unable to make it boot with a GTX 750 Ti.

Folks may want to have a look at this one before it vanishes:
http://setiathome.berkeley.edu/workunit.php?wuid=2230191958

Only completed on one machine, all the others errored out, the ones I've looked at were all "too many ..." found.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Folks may want to have a look at this one before it vanishes:
http://setiathome.berkeley.edu/workunit.php?wuid=2230191958

Only completed on one machine, all the others errored out, the ones I've looked at were all "too many ..." found.

We need to get that Build 3430 app off the server as soon as possible - but to do that, we need more people to test whatever the current replacement is and make sure that doesn't open a similar can of worms.

I'll load up my machines later today as I do the Patch (Tues)(Wednes)Day rounds.

Thanks Richard.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Last version I've seen from Raistmer is version 3500. Over on Beta v8.17 also appears to have the same components as his r3500 release.

Any one else experiencing VERY long 'remaining' time to process a opencl_nvidia_sog work unit?
I am seeing time remaining such as '53985d' (that is about 148 years)

any way to find what is causing this? and a way to fix it?

(Win7 BOINC 7.6.22 x64 AMD quad core - nvidia 730 w/2gb with current driver)

---

ask me again in about 200 years!

Have you been running the app for some time or did you just recently start running these apps?

First time runs of new app have incorrect times to complete as these are estimates.

After you get 11 validated results, the time to complete comes down to a more correct time to complete

Edit 2..

I see it took more than 2 days for your first attempt at crunching on that 730 with very little cpu time. It eventually exceeded the time expected and aborted itself. I'm going to say that SoG r3430 which is what the server currently sends out as stock probably isn't a good fit for your card. As it requires up to 1 core for each work unit on the GPU

How many work units are you running on the CPU?

I know Raistmer has a new version that he is testing for lower end GPUs. Not sure where he is yet on that but that version would probably work better on your card, but we will have to wait for him to decide when it will has been tested enough to be released and then sent to Eric for general release.

According to the apps page for that PC, it seems it was using Cuda50 until recently:

SETI@home v8 8.00 windows_intelx86 (cuda50)
...
Number of tasks today	0
Consecutive valid tasks	1441
Average processing rate	45.19 GFLOPS
Average turnaround time	4.80 days

SETI@home v8 8.12 windows_intelx86 (opencl_nvidia_SoG)
Number of tasks completed	3
Max tasks per day	2
Number of tasks today	0
Consecutive valid tasks	0
Average processing rate	10.74 GFLOPS
Average turnaround time	52.17 days

A possible quick solution is to run the S@h advanced setup prog: Lunatics v0.45 beta3
(FYI, even though it is for advanced users/testers, no one has reported any bugs/issues with it since it was released in May)

...but the problem with that is:
Raistmer won't get a chance to troubleshoot his GPU app,
which is pretty much the most popular one for non-customized setups (aka: stock)

So if you have some tech experience/background, he'll likely appreciate your help...as many with cards below the GTX 750 have been quick to complain but few to help.

Cheers,
Rob :-)

Any one else experiencing VERY long 'remaining' time to process a opencl_nvidia_sog work unit?
I am seeing time remaining such as '53985d' (that is about 148 years)

any way to find what is causing this? and a way to fix it?

(Win7 BOINC 7.6.22 x64 AMD quad core - nvidia 730 w/2gb with current driver)

See above for my two tasks showing almost that long, using 64-bit Windows 10 and a GT 440. NO checkpoints written, even after running for hours.

Appears to need more debugging output, especially in the steps that should write checkpoints, to have much chance of showing what is wrong.


On another subject, how do I tell build 3430 from build 3500?

A possible quick solution is to run the S@h advanced setup prog: Lunatics v0.45 beta3
(FYI, even though it is for advanced users/testers, no one has reported any bugs/issues with it since it was released in May)

...but the problem with that is:
Raistmer won't get a chance to troubleshoot his GPU app,
which is pretty much the most popular one for non-customized setups (aka: stock)

So if you have some tech experience/background, he'll likely appreciate your help...as many with cards below the GTX 750 have been quick to complain but few to help.

Cheers,
Rob :-)

I've done some beta testing for other BOINC projects, and am thinking of trying this with a GT 440 under Windows 10 and a GTX 560 under Windows Vista. However, the Lunatics thread appears to have inadequate instructions on how to start for someone who has never done any beta testing for SETI@home before.