I've installed and up and am up and running but a question that I've not seen answered is it faster or better science or both?

Optimization is primarily aimed at faster. However, we watch very carefully for any tendency to not match the project's stock apps closely, and either fix or remove any errant change.

What it comes down to is that validation should very seldom be inconclusive between the Lunatics apps and stock apps when both are run on stable systems. There will always be some, even between stock and stock, because calculations with varying implementations and running on different hardware don't produce identical results. Occasional inconclusive validations are little burden on the project since a third result usually resolves the uncertainty, but still we try to keep all calculations about 100 times more accurate than the validator requires.

                                                                   Joe

In the past it was recommended that I use the non-HD5 ATi app over the HD5 version. Is that still the case for my Radeon HD 7970?

The message I got from the development team was

Can you please remove "Tahiti core cards may prefer the HD4 app app above" part on MB7 ATI for HD 5.
That's fixed now.

In the past it was recommended that I use the non-HD5 ATi app over the HD5 version. Is that still the case for my Radeon HD 7970?

HD 5 version is faster on 7970 now.
I use it also.

---

With each crime and every kindness we birth our future.

I've installed and up and am up and running but a question that I've not seen answered is it faster or better science or both?

It's still very early, but so far it appears the CPU application improvements are significant.
My i7 2600k makes use of AVX; MB WUs that were taking 4hrs 10/4hrs 16 now appear to be taking around 3hrs 30/3hrs 35. That is a considerable improvement.
My GTX 750Ti makes use of the CUDA50 application which is unchanged, and it's processing time also remains unchanged. Which is good- the CPU application just make better use of it's existing CPU time, and doesn't take up more CPU time to produce the extra processing.


Excellent work people.

---

Grant
Darwin NT

I want to give a BIG SHOUTOUT to all those who gave us this great new process to work with (toy to play with, sic). I do have one question - When will CUDA50 evolve to a 64-bit application, and will we see it in v0.43?

---

I don't buy computers, I build them!!

I want to give a BIG SHOUTOUT to all those who gave us this great new process to work with (toy to play with, sic). I do have one question - When will CUDA50 evolve to a 64-bit application, and will we see it in v0.43?

They have said in the past that native 64-bit app does not give any performance gain. So maybe once gains are present or development of 32-bit app is no longer viable?

---

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

I want to give a BIG SHOUTOUT to all those who gave us this great new process to work with (toy to play with, sic). I do have one question - When will CUDA50 evolve to a 64-bit application, and will we see it in v0.43?

They have said in the past that native 64-bit app does not give any performance gain. So maybe once gains are present or development of 32-bit app is no longer viable?

The only significant difference with a 64-bit cuda app would be the ability to address more then 4GB of VRAM at once. We don't need that for SETI. Even GPUGrid needs less than 2GB of addressable memory space, and that's only for one task sub-type.

But if you switch to 64-bit memory addressing every pointer, every register, every memory update requires 8 bytes. And for a GPU needing to load and return data over the PCIe bus, that's a significant overhead. In fact, memory access/transfer latency is the biggest bottleneck in the cuda ecosystem.

If you want to slow down your SETI cruncher, I'm sure a 64-bit application could be arranged - but I doubt the takeup would be very high, once people saw the initial results.

In the meantime, there are more and better 64-bit apps in the 0.42 installer - where they belong, in the CPU area, to take advantage of the CPU's immediate access to cache and system RAM.

I want to give a BIG SHOUTOUT to all those who gave us this great new process to work with (toy to play with, sic). I do have one question - When will CUDA50 evolve to a 64-bit application, and will we see it in v0.43?

They have said in the past that native 64-bit app does not give any performance gain. So maybe once gains are present or development of 32-bit app is no longer viable?

The only significant difference with a 64-bit cuda app would be the ability to address more then 4GB of VRAM at once. We don't need that for SETI. Even GPUGrid needs less than 2GB of addressable memory space, and that's only for one task sub-type.

But if you switch to 64-bit memory addressing every pointer, every register, every memory update requires 8 bytes. And for a GPU needing to load and return data over the PCIe bus, that's a significant overhead. In fact, memory access/transfer latency is the biggest bottleneck in the cuda ecosystem.

If you want to slow down your SETI cruncher, I'm sure a 64-bit application could be arranged - but I doubt the takeup would be very high, once people saw the initial results.

In the meantime, there are more and better 64-bit apps in the 0.42 installer - where they belong, in the CPU area, to take advantage of the CPU's immediate access to cache and system RAM.

Thanks Richard, even though retired I'm still thinking with my old school mainframe brain where we didn't have to worry about things like this. One of these days I will have to force my mind to think small again.

---

I don't buy computers, I build them!!

My W7 box has been totally reliable for many years now has produced 2 errors with this app.

11:27:02 (3240): Can't acquire lockfile (32) - waiting 35s
11:27:37 (3240): Can't acquire lockfile (32) - exiting
11:27:37 (3240): Error: The process cannot access the file because it is being used by another process

.

---

My W7 box has been totally reliable for many years now has produced 2 errors with this app.

11:27:02 (3240): Can't acquire lockfile (32) - waiting 35s
11:27:37 (3240): Can't acquire lockfile (32) - exiting
11:27:37 (3240): Error: The process cannot access the file because it is being used by another process

.

Could you be a little more specific, please? Which of the 22 different applications available for installation by the installer did you select - and can you try to indentify which one produced that error for us?

Edit - ah, could you be talking about Error tasks for computer 5940036?

I make those
Windows x86 rev 1797, V6 match
### Restart at 21.36 percent.
### Restart at 99.75 percent.

and

Windows x86 rev 1843, V6 match
### Restart at 21.62 percent.
### Restart at 98.20 percent.

Those are both old version numbers, and r1797 is now only delivered to BOINC installations running 'as a service' - which yours can't be, because it's running a GPU under BOINC v7.2.28

It is *possible* - though the diagnosis is far from complete - that the problem arose because the new applications were installed after those two tasks had started running. I'll pass a message on to the developer.

Well one was a CPU task the other GPU.
I selected 64 bit, CUDA 42, not use ATI, not use Intel GPU is what I remember.
It has also produced a fair number of valid tasks.

---

Well one was a CPU task the other GPU.
I selected 64 bit, CUDA 42, not use ATI, not use Intel GPU is what I remember.

Yes, see my edit - one was Astropulse on CPU, the other was Astropulse on NVidia. You must be one of the few to have any AP left at this time of the week!

It is *possible* - though the diagnosis is far from complete - that the problem arose because the new applications were installed after those two tasks had started running.

Well I did have 2 tasks running when I installed. An oddity is that rather than immediately restarting them it started a new pair then later on picked them up but I don't think these are those.
As for APs this machine is so slow it seldom runs out.

---

It is *possible* - though the diagnosis is far from complete - that the problem arose because the new applications were installed after those two tasks had started running.

Well I did have 2 tasks running when I installed. An oddity is that rather than immediately restarting them it started a new pair then later on picked them up but I don't think these are those.
As for APs this machine is so slow it seldom runs out.

Well, I've passed the message on, but it may be a bit too much of a rush to get a reply before we go into maintenance - which I assume will be in about 15 minutes. But I'll get an answer as soon as I can.

I would like to use the "service installation" during the installation of the 0.42 software. I have the following......

Windows 8.1 (64 bit)
Nvidia driver 340.52
Nvidia GPU 780M
Boinc version 7.2.42

Would the problem where the GPU is not recognized rear it's ugly head or would the GPU be usable?

Thanks in advance.

---

Boinc....Boinc....Boinc....Boinc....

I would like to use the "service installation" during the installation of the 0.42 software. I have the following......

Windows 8.1 (64 bit)
Nvidia driver 340.52
Nvidia GPU 780M
Boinc version 7.2.42

Would the problem where the GPU is not recognized rear it's ugly head or would the GPU be usable?

Thanks in advance.

'Service installation' applies to the way you chose to install the BOINC client software - nothing to do with us. With the combination you've listed, if you chose to install BOINC as a service, then your GPU will not be visible to BOINC, and BOINC programs won't be able to use it. That's a fundamental property of the way graphics drivers are handled in Windows Vista, 7, 8(.1), and probably all currently imaginable future versions of Windows.

Even if you installed the Lunatics applications on top of a service installation of BOINC, they would do nada, nothing, zilch. So this time, we've decided to save you the trouble of four useless mouse clicks, and skipped directly to the installation page - the CPU apps will be the only apps you can use for SETI, if you have BOINC installed as a service.

I've installed and up and am up and running but a question that I've not seen answered is it faster or better science or both?

It's still very early, but so far it appears the CPU application improvements are significant.
My i7 2600k makes use of AVX; MB WUs that were taking 4hrs 10/4hrs 16 now appear to be taking around 3hrs 30/3hrs 35. That is a considerable improvement.
My GTX 750Ti makes use of the CUDA50 application which is unchanged, and it's processing time also remains unchanged. Which is good- the CPU application just make better use of it's existing CPU time, and doesn't take up more CPU time to produce the extra processing.

On my E6600 system with 2*GTX 750Tis running the SSSE3 application, longer running CPU WUs would take around 6hrs 10 to 6hrs 30 to crunch. They're now being done in under 6hrs.


For both systems there has been a reduction in crunching time for shorties, but only a few minutes in most cases; but with the longer running WUs crunching times have been reduced from between 15 to as much as 30min.

---

Grant
Darwin NT

Thank you Lunatic people for all of your hard work.

+100 :)

---

It is *possible* - though the diagnosis is far from complete - that the problem arose because the new applications were installed after those two tasks had started running.

Well I did have 2 tasks running when I installed. An oddity is that rather than immediately restarting them it started a new pair then later on picked them up but I don't think these are those.
As for APs this machine is so slow it seldom runs out.

Well, I've passed the message on, but it may be a bit too much of a rush to get a reply before we go into maintenance - which I assume will be in about 15 minutes. But I'll get an answer as soon as I can.

Having discussed this with the developer, we suspect that the problem was most probably the old Astropulse applications failing to shut down promptly when the Installer shut down BOINC - apparently this can happen with the AP apps, perhaps especially with older/slower computers.

Now that everyone will be getting new AP tasks again, it might be wise to shut down BOINC manually, and verify with Task Manager that any Astropulse applications have also closed (aren't running as zombies outside BOINC's control), before using the Installer to deliver the new applications. (I don't think that's ever been necessary if you only run MB apps)

The good news is that Betreger's machine hasn't suffered any further errors since the new apps were installed, and both his CPU and his GPU have reported and validated tasks crunched with the new apps - so this was a transient glitch, at worst.

It appears to be so. I shall crunch on.

---