I have installed on both my machines, they are doing Aps so will wait until they ask for new work and hopefully will get the downloads.

---

BOINC probably thinks you have enough work for the time being. You should see it asking for more as time passes (and before your cache is completely dry), but everything is going to be a little bit out of line for a day or two until it settles down.

And then some.
I did the update this morning before going to work.
Almost 12 hours later & the Result Duration Correction Factor is down to 0.3 & 0.2, CPU run times are pretty close, but the GPU ones are still way over the top (3hrs for WUs that are taking around 15min).

---

Grant
Darwin NT

After running the installer including the brook gpu AstroPulse version I get the following start up message. I tried using my previous app_info.xml file (had been using the brook version previously) but it still gives the same messages. Not sure if this is an SETI or Lunatics problem. I have just disabled GPU processing for now to keep from trashing any more AP tasks. My GPU is a Radeon HD Mobility 3400

03/06/2013 12:07:12 PM | | CAL: ATI GPU 0: ATI Radeon HD 2300/2400/3200/4200 (RV610) (CAL version 1.4.900, 256MB, 224MB available, 80 GFLOPS peak)
03/06/2013 12:07:12 PM | SETI@home | Found app_info.xml; using anonymous platform
03/06/2013 12:07:12 PM | | App version needs OpenCL but GPU doesn't support it
03/06/2013 12:07:12 PM | | App version needs OpenCL but GPU doesn't support it
03/06/2013 12:07:12 PM | | App version needs OpenCL but GPU doesn't support it
03/06/2013 12:07:12 PM | | App version needs OpenCL but GPU doesn't support it
03/06/2013 12:07:12 PM | | App version needs OpenCL but GPU doesn't support it
03/06/2013 12:07:12 PM | | App version needs OpenCL but GPU doesn't support it
03/06/2013 12:07:12 PM | | App version needs OpenCL but GPU doesn't support it
03/06/2013 12:07:12 PM | | App version needs OpenCL but GPU doesn't support it

First of all unhide your PCs on web preferencies.
Check twice brook was selected. send me your app_info in PM.

---

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

As someone using an AMD with a K10 core, a native SSE3 app would be much appreciated. Not everyone is using an Intel CPU with their growing alphabet soup of new advance instruction sets.

Sorry for using a 2 year old AMD processor.

SSE2 should go just fine for you.

---

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

Install went the way it is supposed to.
When Seti restarted GPUZ showed 0 GPU usage.
I shut down Boinc and Seti. Then I restarted them and GPUZ showed 99% usage for a 30 seconds or so then back to zero. The task manager showed 100% CPU usage with or without the GPU running.
Rebooted the computer and Seti started using the GPU at about 99% and promptly thrashed the AP it was working on with

-5 (0xfffffffffffffffb) Unknown error number

. I only had 3 hours into this heavily blank wu.
Now it seems to be happily crunching another AP and my power meter shows I am using about 10 more watts than before.

That looks like task 3016998379

It was started under OPENCL_NV rev 1316, but the error happened when it restarted with the new (installer supplied) r1843. I think Raistmer has warned in the past about changing AP OpenCL application versions mid-task, though I don't think he gave us a warning about this particular upgrade path.

Other people planning to upgrade a host running AP on GPUs might find it safest to suspend cached tasks in the run-up to an upgrade, so that they can upgrade between - rather than during - tasks, at least until we can get Raistmer here to look at the error.

Tasks in progess should never be moved between CPU and GPU and between Brook GPU and anything else. Besides that GPU builds are compatible by checkpoints.

---

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

Install went the way it is supposed to.
When Seti restarted GPUZ showed 0 GPU usage.
I shut down Boinc and Seti. Then I restarted them and GPUZ showed 99% usage for a 30 seconds or so then back to zero. The task manager showed 100% CPU usage with or without the GPU running.
Rebooted the computer and Seti started using the GPU at about 99% and promptly thrashed the AP it was working on with

-5 (0xfffffffffffffffb) Unknown error number

. I only had 3 hours into this heavily blank wu.
Now it seems to be happily crunching another AP and my power meter shows I am using about 10 more watts than before.

That looks like task 3016998379

It was started under OPENCL_NV rev 1316, but the error happened when it restarted with the new (installer supplied) r1843. I think Raistmer has warned in the past about changing AP OpenCL application versions mid-task, though I don't think he gave us a warning about this particular upgrade path.

Other people planning to upgrade a host running AP on GPUs might find it safest to suspend cached tasks in the run-up to an upgrade, so that they can upgrade between - rather than during - tasks, at least until we can get Raistmer here to look at the error.

More probably reason in these lines:

12:06:57 (320): Can't acquire lockfile (32) - waiting 35s
12:07:32 (320): Can't acquire lockfile (32) - exiting
12:07:32 (320): Error: The process cannot access the file because it is being used by another process.

task was not stopped with BOINC shutdown.
Time to time BOINC can't issue correct command for app to quit. So it's worth to check if all apps really stopped after BOINC shutdown.

---

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

Which way would be the 'better' way for 2 WUs/GPU?

Via app_info.xml file or app_config.xml file?

Thanks.

IMHO- app_config, you only need to make the changes in one place, not multiple locations in the file.

The app_config.xml is fine so long as you use BOINC V7, but seeing as the computers are hidden and BOINC V6 maybe used then only the app_info.xml is the only way to go.

Cheers.

So 2.3 is actually faster than 3.2 for a 9800 series card?

In short - yes. Tested om GTX295, GT9400, GSO9600... so, conclusion: CUDA23 is the best choice for pre-FERMI. But your particular host could be an exclusion. Always can be exclusions.

---

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

Sorry, I just don't like the felling, real or not, that it's okay to marginalize AMD CPU owners, lumping them in with a decade old plus deadend like the P4.

Just go to AMD forums and say big "thank you" for their programming tools quality. We use what we have. And regarding OpenCL MB - not so bad as you think.
Regarding 50% speed loss - very probably before you used app compiled with ICC+ IPP with my mods for better performance on AMD. Look, ICC is Intel tool, IPP is Intel tool again (funny, right?). So, go to AMD forum again and add another "Thank you" for their programming tools quality.

---

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

I have question not shore if you have already been asked but anyway

Is it ok to pass this version on to others ?

Has the copy write issue been solved ?

You can freely redistribute as long as you keeping original content intact.

---

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

Yes but I'm running AMD K10 cores in my Llano A8-3820. They don't support SSSE3 or AVX but it does support SSE3. As you can see it's not calling anything that is SSE3 but only SSE2.

And if the FFT dll supports whatever instructions then why do you have three separate apps? There is obviously some difference in compile flags and is it possible that information is passed to the dll?

Anyways here's my WISDOM file

(fftw-3.3 fftwf_wisdom #x08ac4c16 #x457005cc #xea102cf7 #xd7ff9038
(fftwf_dft_nop_register 0 #x11048 #x11048 #x0 #x738e165e #x70f832ba #x489292c9 #x492d5518)
(fftwf_codelet_t2bv_8_sse2 0 #x11bdd #x11bdd #x0 #xe7288594 #xa53b1379 #xc1ea7b45 #xe2150d3e)

This just means that FFTW planning routine tested you CPU and decided that SSE2 is the best.
This just concurs with our own point to drop SSE3: SSE2 performs reasonably well on SSE3 hosts. Moreover, some old AMD Athlon64 CPUs like Venice have quite poor SSE3 implementation. Even older x64 SSE2 apps beat same but SSE3 app on those CPUs, tested personally.
In general - support of some SIMD level means nothing for performance. SSE3 IA can be supported but SSE3 instruction can take so many CPU cycles that better to avoid its usage for performance reasons.

---

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

Heh, this 'poor AMD' thing comes up every time there's some release or another. Guess it's easier to see the wood for the trees having stepped back from CPU development myself for a while.

SSE3 pni, prescott (pentium 4) new instructions main feature is dedicated to horizontal math, while most of the custom code in multibeam is hand striped vertical math (SSE) and prefetch related SSE2 & double precision in places. By coincidence a prior AKv8b2 SSE3 built with Intel Compiler with pentium 4 options turned on was certainly fastest on the older SSE3 AMD, outstripping what we could manage in a 64 bit build on them by over 7%

Unfortunately thanks to litigation brought by the aforementioned company over that compiler & libraries, that compiler is well out of price range of most independant open source developers now (including myself now), and tweaked licenses guarantee fundamental problems with using a similar setup again in an open source distribution.

So I'm afraid for now you're just going to feel lucky to get any build to run on it at all, And if Joe & Raistmer decide to make hand p4-style optimisations that suit those old designs, which I doubt would be well spent effort for 7%, then I wager they'd need a lot more support than this whiney backstabbing performance.

Well thanks for explaining it.

---

"Life is just nature's way of keeping meat fresh." - The Doctor

Sorry, I just don't like the felling, real or not, that it's okay to marginalize AMD CPU owners, lumping them in with a decade old plus deadend like the P4.

Just go to AMD forums and say big "thank you" for their programming tools quality. We use what we have. And regarding OpenCL MB - not so bad as you think.
Regarding 50% speed loss - very probably before you used app compiled with ICC+ IPP with my mods for better performance on AMD. Look, ICC is Intel tool, IPP is Intel tool again (funny, right?). So, go to AMD forum again and add another "Thank you" for their programming tools quality.

When William suggested than an SSE3 offering was possible I was just pointing out that there was a specific AMD SSE3 MB app. BTW, thank you for that.

Didn't Intel get into a bit of PR trouble over intentional inferior performance on AMD cpus with ICC and IPP a few years back? Nevermind.

I was just a bit tweaked when someone simply waved off SSE3 when we (AMD K10 users) had an excellent one once. Seeing how many of the super crunchers who helped test during the V7 beta are overwhelmingly Intel/Cuda, I just wanted to stand up and remind everyone that not all crunchers are Intel/Cuda.

Thank you again Raistmer for your hard work in making these apps possible. I do appreciate it even though I sound like a whinny poster more often than not.

---

"Life is just nature's way of keeping meat fresh." - The Doctor

When William suggested than an SSE3 offering was possible I was just pointing out that there was a specific AMD SSE3 MB app. BTW, thank you for that.

Didn't Intel get into a bit of PR trouble over intentional inferior performance on AMD cpus with ICC and IPP a few years back? Nevermind.

I was just a bit tweaked when someone simply waved off SSE3 when we (AMD K10 users) had an excellent one once. Seeing how many of the super crunchers who helped test during the V7 beta are overwhelmingly Intel/Cuda, I just wanted to stand up and remind everyone that not all crunchers are Intel/Cuda.

Thank you again Raistmer for your hard work in making these apps possible. I do appreciate it even though I sound like a whinny poster more often than not.

LoL, whinning is Ok, being properly targeted. I practice it too time to time ;D

Regarding Intel's "black PR" - yes. Hence those mods - I corrected IPP routines selection. ICC/IPP picked up slower versions for AMD than it could. But funny part is: ICC+IPP still the best/fastest for AMD. Not AMD own tools, but Intel's... It tells a lot IMHO.

And again, to have SSE3 doesn't mean to have faster app. Actually, you will have ability to test by yourself and tell us. Joe's all builds will be released as separate packs soon (including SSE3 dropped from installer for simlicity).

EDIT: we don't forget AMD nethertheless. Just look on my own fleet ;)

---

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

My Q6600 Quad cpu is knocking out V7 workunits in 3-1/2 hours, is this about right?

My E6600 (since installing Lunatics) knocked the last one over in 1hr 23min. The next one is a VLAR and will probably take over 4.5 hours (before Lunatics it was over 7 with v7).
Not sure what the eventual times will be as the estimates are still all over the place, not even close to settling down. GPU estimates are even worse.

---

Grant
Darwin NT

>>>> My Q6600 Quad cpu is knocking out V7 workunits in 3-1/2 hours, is this about right?

My Q6600 is also take that amount of time, so i think we are equal ..

Philip J. Fry wrote:

I could use still CPU r557 of APv6 or I must use now the CPU r1797 app, because the app is 'better' for the results/science?


The AP6_win_x86_SSE_CPU_r1797.exe app comes with an empty ap_cmdline_win_x86_SSE_CPU.txt file.
I could adjust this app?

I read all the README.txt files, but couldn't find infos about.

I could set <cmdline>SSE4.1</cmdline> and the app use this instruction set? ;-D


Thanks.

It's possible to use still r557? Or this app is outdated and make now wrong results?

I D/Led AP6_win_x86_SSE_CPU_r1797.exe separately from Lunatics site, there is an AstroPulse_CPU_ReadMe.txt file included:

AstroPulse CPU application currently available in SSE edition.
It's intended to process SETI@home AstroPulse v6 tasks.

Source code repository: https://setisvn.ssl.berkeley.edu/svn/branches/sah_v7_opt
Build from SVN revision: 1797
Date of revision commit: 2013/03/30 16:42:32

Available command line switches:

-v N :sets level of verbosity of app. N - integer number.

So I just write in ap_cmdline_win_x86_SSE_CPU.txt file:

-v x

.. and this value is used then for what and how I find the correct value for my system?

Thanks.


* Best regards! :-) * Philip J. Fry, team seti.international founder. * Optimize your PC for higher RAC. * SETI@home needs your help. *

---

"verbosity" (ausführlichkeit, according to Google translate) just means how much text is written into the stderr_txt file.

It's a debugging tool, useful to the programmers in testing, but it shouldn't be needed in normal running.

Leave it set at the default level unless you are trying to track down a specific problem: it'll slow your machine down (by a tiny, imperceptible amount), and all that text gets stored on the project servers, too, which isn't a good idea.

Philip J. Fry wrote:

I could use still CPU r557 of APv6 or I must use now the CPU r1797 app, because the app is 'better' for the results/science?

No problems runing the r557 here.

I switched back manualy from the r1797 to the r557 because the r1797 stops chrunching the WU after 50-60% (~6-8 hours on my little C2D T7600) without any reason. In process explorer i can see that the process is not frozen but it dosen't continue the WU ???
After going back to r557 the WU continues, finish and got validated without problems.

For performance the r557 seems to be a little bit quicker - ~2-3% ;-) , but i only tryed 2 WUs.

__W__

---

_______________________________________________________________________________

Philip J. Fry wrote:

I could use still CPU r557 of APv6 or I must use now the CPU r1797 app, because the app is 'better' for the results/science?

No problems runing the r557 here.

I switched back manualy from the r1797 to the r557 because the r1797 stops chrunching the WU after 50-60% (~6-8 hours on my little C2D T7600) without any reason. In process explorer i can see that the process is not frozen but it dosen't continue the WU ???
After going back to r557 the WU continues, finish and got validated without problems.

For performance the r557 seems to be a little bit quicker - ~2-3% ;-) , but i only tryed 2 WUs.

__W__

you can continue to use r557, but we can't put it into the installer any more (or distribute in general). It's Jason's build using statically linked libraries - those are traditionally faster than the dynamically linked ones (i.e. Raistmer's r555 and r1797)

You'll have to ask Raistmer what kind of improvements he did inbetween.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)