Very small visual 7ypo (which don't really need correction) on ATI and Intel pages:
Can you spot it ;)

Mutlibeam:)

edit: late to the show again ...sigh

ATI is a typo too ;) It's been long enough since AMD bought them!

---

Very small visual 7ypo (which don't really need correction) on ATI and Intel pages:
Can you spot it ;)

Mutlibeam :)

edit: late to the show again ...sigh

MutliBeam - I really didn't see this - too small letters on my bad-focus CRT monitor (Philips 201B4 21" 1600x1200) (I was given for free)
(the first blue line have MultiBeam but the black - MutliBeam)

P.S.
In the browser I use abbreviations (for faster typing and to avoid too much thinking about spelling ;) )
I type br` abb` mb` ap` t` app` s` b` (and many others)
and they become browser abbreviations MultiBeam AstroPulse tasks applications SETI@home BOINC
http://setiathome.berkeley.edu/forum_thread.php?id=73694

---

 


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

Actually.....we're all late to the party. Here's the same window from v0.43b.

[img ]http://i65.tinypic.com/ayk6tg.jpg[/img]

I guess none of us really pay attention to details when we're in a hurry to install the latest and greatest! ;^)

Well you are not only late to the party, but you also missed the main error in the 0.44 installer.
You guys might want to give Richard's reply to BilBg's post a read.

In fact "the main error" (MB7_ vs MB8_) is only visual glitch in the GUI - the app_info.xml and .exe files themselves are OK

---

 


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

I used the v0.44 x64 Installer.

In the Installer stay for Intel iGPU: at least driver 9.18.10.3257

In the Intel_driver_Installation_Readme_(64-bit).txt file stay something from (how to install): 10.18.10.3958

So this is irritating.

So I downloaded all new drivers for my board (but didn't installed it until now). Because the 10.18.10.3408 driver worked very well over 1 year.

On my PC the 10.18.10.3408 driver is installed, so the Intel iGPU apps of the v0.44 x64 Installer will work?


I checked the SSE4.2 app for SAHv8.
It installed a SSE3 app.
I unzipped the Lunatics Installer and saw there are just SSE2, SSE3 and AVX apps.

So a SSE4.2 app isn't available like last time for SAHv7?

If so, then a little note somewhere in the Installer that just SSE2, SSE3 and AVX apps are available (just currently, or will come the other in future?) would be nice. ;-)
Because as I saw just the SSE3 app I was confused and thought I did something wrong during Installer usage.
(So I did it a second time.
And then I unzipped the Installer.)

Thanks.

---

So a SSE4.2 app isn't available like last time for SAHv7?

If so, then a little note somewhere in the Installer that just SSE2, SSE3 and AVX apps are available (just currently, or will come the other in future?) would be nice. ;-)

It was mentioned in the opening post of this thread & the installer readme file.

In the continuing absence of Joe Segur (we wish him well, wherever he is), we have only been able to provide a limited range of CPU apps - SSE (not applicable to 64-bit platforms), SSE2, SSE3, and AVX. These have been compiled using Microsoft Visual Studio, and may not be as tightly optimised as Joe's wizardry with GCC 4.7.1. When one of the intermediate SIMD levels like SSSE3 or SSE4.1 is detected by the installer and selected, the SSE3 application will be supplied for v8 tasks, but the matching v7 legacy (AKv8c r2549) application will be supplied for cleaning-up leftover v7 tasks.

---

Grant
Darwin NT

Thanks, Grant - that's one I can cross off my list.

Intel GPU drivers:

The wording on the installer interface says (as Dirk has quoted accurately): at least driver 9.18.10.3257

Drivers earlier than that (with a lower version number than 9.18.....) are OpenCL v1.1 only, and will not work. Later drivers (like the version ten that Dirk is already using) should work, but I don't own examples of every version of the Intel HD GPUs, and I don't spend time testing each new driver release. What I do is to find a stable driver for my hardware, and use that to test the new applications before releasing them.

If driver 10.18.10.3408 was working stably and giving validated results with the previous applications, I think we can say that the same driver will give equally good results with the updated applications: there's no need to change it. If, at some future date, the minimum driver requirement does need to change, I will try to make that clear on the installer interface, in the release notes posted here, and in the internal supplied documentation.

The installation notes for Intel drivers in general are supplied as a courtesy to volunteers setting up an Intel GPU based BOINC platform in general. Some people (including me) have found that Intel OpenCL drivers are not supplied by default on all new computers fitted with compatible GPUs: and/or, the Intel automatic installers fail and say (falsely) that compatible hardware is not present on some machines.

As the opening post in this thread also says:

Many people have reported problems getting Intel's automated update and installation tools to work, but their manual installation instructions (requiring the download of the '.zip' driver package) appear to work on systems which reject the automated tools. A copy of Intel's ReadMe file for driver installation will be placed in the Lunatics docs folder for reference if you select either of the iGPU applications.

Thanks, Grant - that's one I can cross off my list.

Intel GPU drivers:

The wording on the installer interface says (as Dirk has quoted accurately): at least driver 9.18.10.3257

Drivers earlier than that (with a lower version number than 9.18.....) are OpenCL v1.1 only, and will not work. Later drivers (like the version ten that Dirk is already using) should work, but I don't own examples of every version of the Intel HD GPUs, and I don't spend time testing each new driver release. What I do is to find a stable driver for my hardware, and use that to test the new applications before releasing them.

If driver 10.18.10.3408 was working stably and giving validated results with the previous applications, I think we can say that the same driver will give equally good results with the updated applications: there's no need to change it. If, at some future date, the minimum driver requirement does need to change, I will try to make that clear on the installer interface, in the release notes posted here, and in the internal supplied documentation.

The installation notes for Intel drivers in general are supplied as a courtesy to volunteers setting up an Intel GPU based BOINC platform in general. Some people (including me) have found that Intel OpenCL drivers are not supplied by default on all new computers fitted with compatible GPUs: and/or, the Intel automatic installers fail and say (falsely) that compatible hardware is not present on some machines.

As the opening post in this thread also says:

Many people have reported problems getting Intel's automated update and installation tools to work, but their manual installation instructions (requiring the download of the '.zip' driver package) appear to work on systems which reject the automated tools. A copy of Intel's ReadMe file for driver installation will be placed in the Lunatics docs folder for reference if you select either of the iGPU applications.

I have been running the Lunatics Intel GPU app here and the stock Intel GPU app on Beta, on an HD 4600, using the most recent driver (version 10.18.14.4264, dated 4 August 2015), without encountering any problems at all.

---

I have been running the Lunatics Intel GPU app here and the stock Intel GPU app on Beta, on an HD 4600, using the most recent driver (version 10.18.14.4264, dated 4 August 2015), without encountering any problems at all.

Thanks John, good to know that version works as well - at least for SETI.

If it's working, I'd leave well alone: but technically speaking, it isn't the "most recent". Looking on the Intel web site, I found

Version: 15.36.28.4332 (Latest) Date: 12/11/2015

Unpacking the zip, the internal documentation describes it as

Release Version: Production Version

Intel(R) Graphics Driver: 10.18.14.4332
Intel(R) Display Audio Driver: 6.16.0.3174

Package: 514951

Operating System(s):   

Microsoft Windows* 7 64-bit
Microsoft Windows* 8.1 64-bit

Release Date: November 30, 2015

(separate 32-bit versions, and versions for Windows 10, are also available. The discrepancy between download version numbers/dates and driver version numbers/dates continues to irritate me.)

This is not a recommendation to upgrade: more a reminder to myself that perhaps I ought to test it, both here and at Einstein, before the next installer release.

I have been running the Lunatics Intel GPU app here and the stock Intel GPU app on Beta, on an HD 4600, using the most recent driver (version 10.18.14.4264, dated 4 August 2015), without encountering any problems at all.

Thanks John, good to know that version works as well - at least for SETI.

If it's working, I'd leave well alone: but technically speaking, it isn't the "most recent". Looking on the Intel web site, I found

Version: 15.36.28.4332 (Latest) Date: 12/11/2015

Unpacking the zip, the internal documentation describes it as

Release Version: Production Version

Intel(R) Graphics Driver: 10.18.14.4332
Intel(R) Display Audio Driver: 6.16.0.3174

Package: 514951

Operating System(s):   

Microsoft Windows* 7 64-bit
Microsoft Windows* 8.1 64-bit

Release Date: November 30, 2015

(separate 32-bit versions, and versions for Windows 10, are also available. The discrepancy between download version numbers/dates and driver version numbers/dates continues to irritate me.)

This is not a recommendation to upgrade: more a reminder to myself that perhaps I ought to test it, both here and at Einstein, before the next installer release.

Their versioning does leave something to be desired. From my rough observations this is what I'm finding.
15.33.xx.xxxx (driver 10.18.10.xxxx) 7th generation iGPU. Ivy Bridge, Haswell, BayTrail.
15.36.xx.xxxx (driver 10.18.10.39xx & driver 10.18.14.4xxx) 7/8th generation iGPU. Haswell & Broadwell.
15.40.xx.xxxx (driver 20.19.15.xxxx) 9th generation iGPU. Skylake.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Hey Richard,

Suddenly I'm having trouble with one of my systems. It's 6260596. It is throwing GPU work in the scraper on a regular basis. I don't know if it's something I've done (more than likely) or just a fluke. I was hoping you might take a look and see if you can tell me what's happening.

I'm using your software and the latest Boinc. It was running fine with 2 GPU units running at one time and then I saw it was stumbling and I changed the app_config to only run one at a time.

I should tell you that I tried to upgrade the driver on the nVidia card and the whole system locked up and I had to shut it down and reboot. When it came up it said there was no driver, so I went back to an older driver and then everything appeared to be okay until I checked it the next day and it was acting up again.

I'd sure appreciate you taking a look see and letting me know how I screwed it up.

Thanks a bunch,

Allen

---

could it be because you were running cuda 5.0 on a 650ti that has a compute capability of 3.0

could it be because you were running cuda 5.0 on a 650ti that has a compute capability of 3.0

Could be.

"CUDA driver version is insufficient for CUDA runtime version."

From task 4681187393:

setiathome_CUDA: CUDA Device 1 specified, checking...
Device cannot be used
Cuda device initialisation retry 1 of 6, waiting 5 secs...
Cuda error 'Couldn't get cuda device count
' in file 'C:/[Projects]/__Sources/sah_v7_opt/Xbranch/client/cuda/cudaAcceleration.cu' in line 138 : CUDA driver version is insufficient for CUDA runtime version.
setiathome_CUDA: cudaGetDeviceCount() call failed.
setiathome_CUDA: No CUDA devices found
setiathome_CUDA: Found 0 CUDA device(s):
nVidia Driver Version {blank}

This is what it looks like now you've gone back up to a more recent driver:

v8 task detected
setiathome_CUDA: Found 1 CUDA device(s):
nVidia Driver Version 358.91
Device 1: GeForce GTX 650 Ti, 1024 MiB, regsPerBlock 65536
computeCap 3.0, multiProcs 4
pciBusID = 2, pciSlotID = 0
In cudaAcc_initializeDevice(): Boinc passed DevPref 1
setiathome_CUDA: CUDA Device 1 specified, checking...
Device 1: GeForce GTX 650 Ti is okay
SETI@home using CUDA accelerated device GeForce GTX 650 Ti
pulsefind: blocks per SM 4 (Fermi or newer default)
pulsefind: periods per launch 100 (default)
Priority of process set to BELOW_NORMAL (default) successfully
Priority of worker thread set successfully

setiathome enhanced x41zi (baseline v8), Cuda 5.00

That's a Kepler core (GK106), so cuda50 should be a good choice - stick with that, and see how it goes. Don't ever drop to a driver earlier than 306.23 with that application.

could it be because you were running cuda 5.0 on a 650ti that has a compute capability of 3.0

Could be.

"CUDA driver version is insufficient for CUDA runtime version."

From task 4681187393:

setiathome_CUDA: CUDA Device 1 specified, checking...
Device cannot be used
Cuda device initialisation retry 1 of 6, waiting 5 secs...
Cuda error 'Couldn't get cuda device count
' in file 'C:/[Projects]/__Sources/sah_v7_opt/Xbranch/client/cuda/cudaAcceleration.cu' in line 138 : CUDA driver version is insufficient for CUDA runtime version.
setiathome_CUDA: cudaGetDeviceCount() call failed.
setiathome_CUDA: No CUDA devices found
setiathome_CUDA: Found 0 CUDA device(s):
nVidia Driver Version {blank}

This is what it looks like now you've gone back up to a more recent driver:

v8 task detected
setiathome_CUDA: Found 1 CUDA device(s):
nVidia Driver Version 358.91
Device 1: GeForce GTX 650 Ti, 1024 MiB, regsPerBlock 65536
computeCap 3.0, multiProcs 4
pciBusID = 2, pciSlotID = 0
In cudaAcc_initializeDevice(): Boinc passed DevPref 1
setiathome_CUDA: CUDA Device 1 specified, checking...
Device 1: GeForce GTX 650 Ti is okay
SETI@home using CUDA accelerated device GeForce GTX 650 Ti
pulsefind: blocks per SM 4 (Fermi or newer default)
pulsefind: periods per launch 100 (default)
Priority of process set to BELOW_NORMAL (default) successfully
Priority of worker thread set successfully

setiathome enhanced x41zi (baseline v8), Cuda 5.00

That's a Kepler core (GK106), so cuda50 should be a good choice - stick with that, and see how it goes. Don't ever drop to a driver earlier than 306.23 with that application.

Thanks for checking it out for me, but I must have misspoken or didn't make myself understood (not rare for me) but what I had done was to upgrade the driver in the first place to the latest version and everything when South. I believe this is the same driver that I had before everything went wrong....when I tried to upgrade...ugh!

Thanks, I will keep an eye on it and get back to you if work keeps getting dumped into the abyss.

Thanks a bunch Richard. Btw, this card was running v7 version with Cuda 50 forever.

---

I was just investigating my last failed unit on the same system...650ti...and it said that it had 8 spikes and 7 triplets, but bad computation. One of the completed okay units done by someone else said 8 spikes and 7 triplets but it finished fine. How does this work? If we both found the same thing, why is one bad and one okay? Just trying to learn.

Allen

---

Thanks for checking it out for me, but I must have misspoken or didn't make myself understood (not rare for me) but what I had done was to upgrade the driver in the first place to the latest version and everything when South.

When you have a driver that works why would you "upgrade"? I've learned the hard way many times if it's not broken don't fix it.

---

Thanks for checking it out for me, but I must have misspoken or didn't make myself understood (not rare for me) but what I had done was to upgrade the driver in the first place to the latest version and everything when South.

When you have a driver that works why would you "upgrade"? I've learned the hard way many times if it's not broken don't fix it.

Good question. I guess I just thought that perhaps they had made some improvements in the code and it might perform better. I guess I've learned my lesson.

---

I was just investigating my last failed unit on the same system...650ti...and it said that it had 8 spikes and 7 triplets, but bad computation. One of the completed okay units done by someone else said 8 spikes and 7 triplets but it finished fine. How does this work? If we both found the same thing, why is one bad and one okay? Just trying to learn.

Allen

When you see in the stderr_txt is not the actual result data that is being compared by the server. It is just kind of a summary.
The spikes could have been found in different places or their power levels could be to different to be a match.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Thanks for checking it out for me, but I must have misspoken or didn't make myself understood (not rare for me) but what I had done was to upgrade the driver in the first place to the latest version and everything when South.

When you have a driver that works why would you "upgrade"? I've learned the hard way many times if it's not broken don't fix it.

Good question. I guess I just thought that perhaps they had made some improvements in the code and it might perform better. I guess I've learned my lesson.

The experts here usually test new drivers and will post whether they are better for crunching, worse, don't work at all, or make no difference (which is the case most often).

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

Thanks for checking it out for me, but I must have misspoken or didn't make myself understood (not rare for me) but what I had done was to upgrade the driver in the first place to the latest version and everything when South.

When you have a driver that works why would you "upgrade"? I've learned the hard way many times if it's not broken don't fix it.

Good question. I guess I just thought that perhaps they had made some improvements in the code and it might perform better. I guess I've learned my lesson.

The experts here usually test new drivers and will post whether they are better for crunching, worse, don't work at all, or make no difference (which is the case most often).

And yet you have to understand that they cannot possibly test all drivers on all platforms.....so therein is the statement given on the Lunatics home page about the new installer...............

YMMV. Your mileage may vary.

---

"Time is simply the mechanism that keeps everything from happening all at once."

I guess I just thought that perhaps they had made some improvements in the code and it might perform better. I guess I've learned my lesson.

The huge majority of driver updates are purely related to gaming issues. A small portion of them relate to general bug fixes.

On NVidia's driver download page, once you've found a new driver, if you click on the Additional Information tab, then the release notes (or Game Ready Driver Release notes) and open up that PDF you can then check to see if there is anything updated that relates to number crunching.
The "What's New" section is where the general summary is, and "Changes & Fixed Issues" gives an item by item list of issues that have been fixed since the previous driver version.

---

Grant
Darwin NT