Is there any chance that one of you guys that are up and running with your 470s / 480s, could post an idiots guid to installing Fermi friendly SETI. I bought two 470s before I found out that they don't run to well on regular SETI (6.10.43). I have tried following the threads but end up with nothing. Please help. Thanks.

OK, I think it's been tested enough now: let's go.

I see you are running optimised apps already. That's essential: you will need to modify an existing app_info.xml file.

You will need to add a whole new <app_version> section:

    <app_version>
        <app_name>setiathome_enhanced</app_name>
    	<version_num>610</version_num>
    	<avg_ncpus>0.200000</avg_ncpus>
    	<max_ncpus>0.200000</max_ncpus>
    	<plan_class>cuda_fermi</plan_class>
	<file_ref>
            <file_name>setiathome_6.10_windows_intelx86__cuda_fermi.exe</file_name>
            <main_program/>
	</file_ref>
	<file_ref>
            <file_name>cudart32_30_14.dll</file_name>
	</file_ref>
   	<file_ref>
            <file_name>cufft32_30_14.dll</file_name>
   	</file_ref>
	<file_ref>
            <file_name>libfftw3f-3-1-1a_upx.dll</file_name>
   	</file_ref>
	<coproc>
            <type>CUDA</type>
            <count>1</count>
	</coproc>
    </app_version>

You'll also have to add <file_info> sections for any file you're not already using. You may have libfftw3f-3-1-1a_upx.dll already, in which case you don't need to add it again: but the full set is

    <file_info>
        <name>setiathome_6.10_windows_intelx86__cuda_fermi.exe</name>
        <executable/>
    </file_info>
    <file_info>
        <name>cudart32_30_14.dll</name>
        <executable/>
    </file_info>
    <file_info>
        <name>cufft32_30_14.dll</name>
        <executable/>
    </file_info>
    <file_info>
        <name>libfftw3f-3-1-1a_upx.dll</name>
        <executable/>
    </file_info>

Finally, you'll need the files themselves: download from

http://boinc2.ssl.berkeley.edu/beta/download/setiathome_6.10_windows_intelx86__cuda_fermi.exe (2,476 KB)
http://boinc2.ssl.berkeley.edu/beta/download/cudart32_30_14.dll (280 KB)
http://boinc2.ssl.berkeley.edu/beta/download/cufft32_30_14.dll (12,188 KB)
http://boinc2.ssl.berkeley.edu/beta/download/libfftw3f-3-1-1a_upx.dll (439 KB)

Make sure the file sizes are correct - sometimes these manual downloads crash out early.

Richards latest post should separated out and put as a sticky so people see that there is a quick solution inside that thread..

My 2 cents :)

Regards Vyper

---

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group

Richards latest post should separated out and put as a sticky so people see that there is a quick solution inside that thread..

My 2 cents :)

Regards Vyper

+1
Will red cross help us in that?

-> <- will info the Mods.
They could move Richard's message out of this thread and start a new thread with it.



Maybe some questions are open..

• The ReSchedule tool* work with 6.10 app? I guess the stock 6.10 don't have a VLAR kill function. (Or it's not longer needed, because the 6.10 app calculate well this kind of AR WUs?)
  
• 6.10 app use the whole Fermi chip?
  
• Which performance is to expect?
  

[EDIT: * 6.09 work with ReSchedule V1.9, 6.09 -> 6.03, so it work for me. But maybe not 6.03 -> 6.09 . **]
[EDIT#2: ** stock apps]

---

Thanks for the info Richard.

Tried editing the app_info file in word 2007 saving it as an xml file and got the following results -

22/05/2010 13:53:59 Starting BOINC client version 6.10.18 for windows_intelx86
22/05/2010 13:53:59 log flags: file_xfer, sched_ops, task
22/05/2010 13:53:59 Libraries: libcurl/7.19.4 OpenSSL/0.9.8l zlib/1.2.3
22/05/2010 13:53:59 Data directory: C:\ProgramData\BOINC
22/05/2010 13:53:59 Running under account R Turnbull
22/05/2010 13:53:59 Processor: 8 GenuineIntel Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz [x86 Family 6 Model 26 Stepping 4]
22/05/2010 13:53:59 Processor: 256.00 KB cache
22/05/2010 13:53:59 Processor features: fpu tsc pae nx sse sse2 pni mmx
22/05/2010 13:53:59 OS: Microsoft Windows Vista: Home Premium x86 Edition, Service Pack 2, (06.00.6002.00)
22/05/2010 13:53:59 Memory: 3.00 GB physical, 6.21 GB virtual
22/05/2010 13:53:59 Disk: 228.85 GB total, 168.67 GB free
22/05/2010 13:53:59 Local time is UTC +1 hours
22/05/2010 13:53:59 NVIDIA GPU 0: GeForce GTX 470 (driver version 19745, CUDA version 3000, compute capability 2.0, 1248MB, 181 GFLOPS peak)
22/05/2010 13:53:59 SETI@home Found app_info.xml; using anonymous platform
22/05/2010 13:53:59 SETI@home [error] State file error: bad application name astropulse_v5
22/05/2010 13:53:59 Not using a proxy
22/05/2010 13:53:59 SETI@home URL http://setiathome.berkeley.edu/; Computer ID 4944207; resource share 100
22/05/2010 13:53:59 SETI@home General prefs: from SETI@home (last modified 06-May-2010 14:32:21)
22/05/2010 13:53:59 SETI@home Computer location: home
22/05/2010 13:53:59 SETI@home General prefs: no separate prefs for home; using your defaults
22/05/2010 13:53:59 Reading preferences override file
22/05/2010 13:53:59 Preferences limit memory usage when active to 1534.88MB
22/05/2010 13:53:59 Preferences limit memory usage when idle to 3069.77MB
22/05/2010 13:53:59 Preferences limit disk usage to 100.00GB
22/05/2010 13:53:59 SETI@home Sending scheduler request: To fetch work.
22/05/2010 13:53:59 SETI@home Requesting new tasks for GPU
22/05/2010 13:54:04 SETI@home Scheduler request completed: got 0 new tasks
22/05/2010 13:54:04 SETI@home Message from server: No work sent
22/05/2010 13:54:04 SETI@home Message from server: No work is available for Astropulse v5
22/05/2010 13:54:04 SETI@home Message from server: Your app_info.xml file doesn't have a version of SETI@home Enhanced.

I looked at the edited xml file and everyting that was typed in came out as one line even though I pressed enter where it needed a new line -

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
- <app_info>
- <app>
<name>setiathome_enhanced</name>
</app>
- <file_info>
<name>AK_v8b_win_SSE_p3.exe</name>
<executable />
</file_info>
- <app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>528</version_num>
- <file_ref>
<file_name>AK_v8b_win_SSE_p3.exe</file_name>
<main_program />
</file_ref>
</app_version>
- <app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>603</version_num>
- <file_ref>
<file_name>AK_v8b_win_SSE_p3.exe</file_name>
<main_program />
</file_ref>
</app_version>
- <app>
<name>astropulse_v5</name>
</app>
- <file_info>
<name>ap_5.03r112_SSE.exe</name>
<executable />
</file_info>
- <app_version>
<app_name>astropulse_v5</app_name>
<version_num>503</version_num>
- <file_ref>
<file_name>ap_5.03r112_SSE.exe</file_name>
<main_program />
</file_ref>
</app_version>
- <app>
<name>astropulse_v505</name>
</app>
- <file_info>
<name>ap_5.05r168_SSE.exe</name>
<executable />
</file_info>
- <app_version>
<app_name>astropulse_v505</app_name>
<version_num>505</version_num>
- <file_ref>
<file_name>ap_5.05r168_SSE.exe</file_name>
<main_program />
</file_ref>
</app_version>
<app_version><app_name>setiathome_enhanced</app_name><version_num>610</version_num><avg_ncpus>0.200000</avg_ncpus><max_ncpus>0.200000</max_ncpus><plan_class>cuda_fermi</plan_class><file_ref><file_name>setiathome_6.10_windows_intelx86__cuda_fermi.exe</file_name><main_program/></file_ref><file_ref><file_name>cudart32_30_14.dll</file_name></file_ref><file_ref><file_name>cufft32_30_14.dll</file_name></file_ref><file_ref><file_name>libfftw3f-3-1-1a_upx.dll</file_name></file_ref><coproc><type>CUDA</type><count>1</count></coproc></app_version>
- <app>
<name>setiathome_enhanced</name>
</app>
- <file_info>
<name>MB_6.08_CUDA_V12_VLARKill_FPLim2048.exe</name>
<executable />
</file_info>
- <file_info>
<name>cudart.dll</name>
<executable />
</file_info>
- <file_info>
<name>cufft.dll</name>
<executable />
</file_info>
<file_info><name>setiathome_6.10_windows_intelx86__cuda_fermi.exe</name><executable/></file_info><file_info><name>cudart32_30_14.dll</name><executable/></file_info><file_info><name>cufft32_30_14.dll</name><executable/></file_info>
- <file_info>
<name>libfftw3f-3-1-1a_upx.dll</name>
<executable />
</file_info>
- <app_version>
<app_name>setiathome_enhanced</app_name>
<version_num>608</version_num>
<plan_class>cuda</plan_class>
<avg_ncpus>0.040000</avg_ncpus>
<max_ncpus>0.040000</max_ncpus>
- <coproc>
<type>CUDA</type>
<count>1</count>
</coproc>
- <file_ref>
<file_name>MB_6.08_CUDA_V12_VLARKill_FPLim2048.exe</file_name>
<main_program />
</file_ref>
- <file_ref>
<file_name>cudart.dll</file_name>
</file_ref>
- <file_ref>
<file_name>cufft.dll</file_name>
</file_ref>
- <file_ref>
<file_name>libfftw3f-3-1-1a_upx.dll</file_name>
</file_ref>
</app_version>
</app_info>

I also looked at the xml page with notepad but that made my eyes water.

Another question, I was hoping to use both my 470s in the one machine would I have to change the lines -

<type>CUDA</type>
<count>1</count>

to

<type>CUDA</type>
<count>2</count>

??

Once again Richard, thanks for your help.

---

@Richard Turnbull

You need to only use Notepad, other Editor's put extra Rogue characters in,

Leave the count value at '1', this means how many GPU's required to run app.

Claggy

@Richard, please read this and PM or email me changes, please. :)

---

* The ReSchedule tool* work with 6.10 app? I guess the stock 6.10 don't have a VLAR kill function. (Or it's not longer needed, because the 6.10 app calculate well this kind of AR WUs?)

Hm, better to use 609 version marker IMO. AFAIK 610 not supported by ReSchedule.
VLAR performance drop still with us so ReSchedule required for best performance.

@Richard, please read this and PM or email me changes, please. :)

This is perfect, i would've simlpified it a little bit more to include that the boinc working directory usually lies at c:\documents and settings\all user\application data\boinc or c:\programdata\boinc too.

So that they could use it too.. Perhaps a downloadable app.info as well so they don't mistakely open it in word :)

Regards Vyper

---

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group

Noobified. Thx.

As for the app_info.xml file, I'm not sure if this is just an addition, or that it will work by itself as well, so didn't say that. Went with the info Richard gave in this thread. If anyone can tell me, please let me know.

Or give an example of how this works in its own app_info.xml

---

Hey now we're talking.. New sticky plix with a link to that :)

Quick response and well done s@h lads.. This is what i'm talking about on my profile.
True spirit of the s@h community.

I'm impressed once again and a proud cruncher.

Kind regards Vyper

P.S Ageless thanks for your work D.S

---

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group

Inserted lines of code at the bottom of existing, using Notepad and saving using ANSI. Reinstalled the 470, but the WUs are still crunching in around 20 seconds, which, going by the last time I uploaded one, gives a return of about 0.01 credits. However there is a plus point, SETI didn't dump all my finished or unused WUs. Have reinstalled my GTX 275 for now, as I have to go out. Will try again later.

---

* The ReSchedule tool* work with 6.10 app? I guess the stock 6.10 don't have a VLAR kill function. (Or it's not longer needed, because the 6.10 app calculate well this kind of AR WUs?)

Hm, better to use 609 version marker IMO. AFAIK 610 not supported by ReSchedule.
VLAR performance drop still with us so ReSchedule required for best performance.

Reschedule doesn't work with 609 either: or, according to a recent posting by Marius, it only works with <plan_class> cuda, not cuda23 or cuda_fermi.

Please leave it at 610: I posted that for a reason. Explanations later: onging tests in progress.

* The ReSchedule tool* work with 6.10 app? I guess the stock 6.10 don't have a VLAR kill function. (Or it's not longer needed, because the 6.10 app calculate well this kind of AR WUs?)

Hm, better to use 609 version marker IMO. AFAIK 610 not supported by ReSchedule.
VLAR performance drop still with us so ReSchedule required for best performance.

Reschedule doesn't work with 609 either: or, according to a recent posting by Marius, it only works with <plan_class> cuda, not cuda23 or cuda_fermi.

Please leave it at 610: I posted that for a reason. Explanations later: onging tests in progress.

For ReSchedule compatibility with Anonymous platform mechanism 608 + plan class cuda can still be used, not need to go into cuda_fermi.
BOINC should be able to ask for GPU work, it can do it with cuda plan class too.
Different driver and onboard memory requirements will be on user as usual when anonymous platform mechanism involved.

* The ReSchedule tool* work with 6.10 app? I guess the stock 6.10 don't have a VLAR kill function. (Or it's not longer needed, because the 6.10 app calculate well this kind of AR WUs?)

Hm, better to use 609 version marker IMO. AFAIK 610 not supported by ReSchedule.
VLAR performance drop still with us so ReSchedule required for best performance.

Reschedule doesn't work with 609 either: or, according to a recent posting by Marius, it only works with <plan_class> cuda, not cuda23 or cuda_fermi.

Please leave it at 610: I posted that for a reason. Explanations later: onging tests in progress.

For ReSchedule compatibility with Anonymous platform mechanism 608 + plan class cuda can still be used, not need to go into cuda_fermi.
BOINC should be able to ask for GPU work, it can do it with cuda plan class too.
Different driver and onboard memory requirements will be on user as usual when anonymous platform mechanism involved.

From my experiences, with app_info.xml (609 entry + stock 6.09 app or opt. 6.08 app) also without app_info.xml (all stock (6.03 & 6.09) apps), it's possible to make '6.09 WUs' to '6.03 WUs'. I guess it don't work 6.03 -> 6.09 .

---

* The ReSchedule tool* work with 6.10 app? I guess the stock 6.10 don't have a VLAR kill function. (Or it's not longer needed, because the 6.10 app calculate well this kind of AR WUs?)

Hm, better to use 609 version marker IMO. AFAIK 610 not supported by ReSchedule.
VLAR performance drop still with us so ReSchedule required for best performance.

Reschedule doesn't work with 609 either: or, according to a recent posting by Marius, it only works with <plan_class> cuda, not cuda23 or cuda_fermi.

Please leave it at 610: I posted that for a reason. Explanations later: ongoing tests in progress.

OK, from later replies, I agree: if ReSchedule does work on <plan_class> alone, then using 'cuda' on its own in the app_info would allow rescheduling: and there would be no need to change version numbers.

I chose v6.10 because that's the version number which is installed and working at Beta - the Beta v6.09/fermi installation was faulty and didn't work. From previous experience with v6.08/cuda and v6.09/cuda23, once a working installation has been tested at Beta, it is copied with the same version numbers to the Main project. So I attempted a pre-emptive strike - getting the numbers right before they happened ;-)

This is partly because of a heart-felt oberservation by Eric, during one of several debugging sessions behind the scenes (Eric wasn't doing the debugging - he's far too busy for that - but I copied him in for information while David and I were tracking something down at Beta). The subject was validation.

Eric Korpela wrote:

We'll be looking. I've got a rash of reports of cuda24 problems
suddenly. I'm hoping that it was just some bad workunits rather than
some more complicated server side problem. The plethora of GPU
platforms is going to start looking like the original SETI@home
platform list. Only worse, because it won't even be the same source
code and each one will need server side changes.

We should remember that we're not just here for our own selfish interest. We are each part of a wider community, and - crucially - that community includes, nay relies on, four overworked and overstressed individual human beings at Berkeley. Their convenience comes pretty high up on my list of priorities. That's why I held off from posting the Fermi information until I had confidence, from personal testing, that the stock application worked reliably and could be added as seamlessly as possible to the main project mix.

And while I'm on the subject of the staff, could I suggest that those of us who are prepared and able to pay top dollar for a brand-new technology should also consider making a voluntary 'service facility fee' contribution? I'm sure the recent upload problems are not entirely unrelated to the recent increase in throughput from high-powered GPUs. 'Nuff said.

And while I'm on the subject of the staff, could I suggest that those of us who are prepared and able to pay top dollar for a brand-new technology should also consider making a voluntary 'service facility fee' contribution? I'm sure the recent upload problems are not entirely unrelated to the recent increase in throughput from high-powered GPUs. 'Nuff said.

Just Donated, and have my Star again. :)

Claggy

And while I'm on the subject of the staff, could I suggest that those of us who are prepared and able to pay top dollar for a brand-new technology should also consider making a voluntary 'service facility fee' contribution? I'm sure the recent upload problems are not entirely unrelated to the recent increase in throughput from high-powered GPUs. 'Nuff said.

Just Donated, and have my Star again. :)

Claggy

I have been planning to donate for quite some time. I'll do it today as soon as my wife takes a shower and can't see me whip out the plastic.

Steve

---

Warning, addicted to SETI crunching!
Crunching as a member of GPU Users Group.
GPUUG Website

I have been planning to donate for quite some time. I'll do it today as soon as my wife takes a shower and can't see me whip out the plastic.

Steve

:-D

---

Only worse, because it won't even be the same source
code and each one will need server side changes.

This sad fact designates big BOINC's design flaw I pointed out on first CUDA plan class apearance.
Each new device treated as something unique and needs changes in everything. Absolutely lifeless approach. It will work for 1-2 devices, but just as Eric said if there are really MANY devices, something more generalized needed.
New level of abstraction. Coprocessor device abstraction.
It has some common attributes. Only values of those attributes need to be changed.
That's whole object-oriented programming about, no need to invent wheel for each new model of auto...