You would need, as a minimum,

http://boinc2.ssl.berkeley.edu/sah/download_fanout/setiathome_7.00_windows_intelx86.exe
http://boinc2.ssl.berkeley.edu/sah/download_fanout/libfftw3f-3-3_upx.dll

I've deliberately not made them clickable, because I want casual readers to stop and think before downloading.

The file sizes are 484,352 and 1,049,920 bytes respectively. Internet Explorer seems to have a habit of truncating manual downloads: Chrome seems better.

I was a bit late in noticing that the new v7 has been released. Is the file compatible with AMD CPU's, as it explicitly mentions intelx86 in the name?

I guess the following changes would be sufficient for the app_info file

    <app>
        <name>setiathome_v7</name>
    </app>
    <file_info>
        <name>setiathome_7.00_windows_intelx86.exe</name>
        <executable/>
    </file_info>
    <file_info>
        <name>libfftw3f-3-3_upx.dll</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>setiathome_v7</app_name>
        <version_num>700</version_num>
	<platform>windows_intelx86</platform>
        <file_ref>
            <file_name>setiathome_7.00_windows_intelx86.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>

______________

Yes, the above mentioned CPU app is for AMD and Intel CPUs.


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

---

This extra search processing (Autocorrelations) will tend to limit the optimal number of tasks run simultaneously per GPU, to a lower figure, and run somewhat cooler. and of course more work takes longer ;)

At least untill the nest round of optimisations & new hardware.
:-)

---

Grant
Darwin NT

Claggy

Don't think so mate.

At the moment things seem to be running wellish. Over the last 2.5 hours I have only received 3 x cuda50 GPU WUs, and 2 x AP WUs on boxes that I don't want AP on. All were aborted.

I will say something though that I think you should look at.

The limiting of the GPU allocation to 0.02 CPUs or 0.03 CPUs has the effect of nobbling the GPU. The limit should be upwards of 0.10 CPU (I ran my boxes at 0.20 CPU per GPU prior to v7 migration).

What this does is to ensure that the GPU gets the resources it needs when it needs them. In observing my systems, I have seen utilisation regularly jump to 0.07 - 0.14. In using 0.20 CPUs, it doesn't mean that it has 0.20 CPUs allocated permanently to the GPU. If the GPU isn't using it, then the processor will. It's just an allocation of resource issue that keeps the GPUs munching as fast as they can.

And I have tried this in the past on the Q6600 with 2 x GTX580s and there is a performance improvement.

cheers mate

---

This extra search processing (Autocorrelations) will tend to limit the optimal number of tasks run simultaneously per GPU, to a lower figure, and run somewhat cooler. and of course more work takes longer ;)

At least untill the nest round of optimisations & new hardware.
:-)

I think I am missing something here. I did notice that no new tasks are being download for the GPU. Can the v7 application be run on the GPU as well? Or is there another file out there somewhere?
______________

Was able to contact Eric.
He said he would turn off Coral Cache on one of the download servers.
I have to run off to work right now, but please keep an eye on things and post here if it helps the app download situation.

Keep in mind you may not hit that particular download server on every attempt, so I would still expect some download failures. But hopefully it will help.

Meow!

I hope the app download crisis has now passed for most of us.
I think the kitties have all they need, and are crunching in v7 style on all rigs now.

But, I did get a more detailed response from Eric this morning.
Unfortunately, I had to rush off to work before I could repost it to you.
But, it might still be some interesting information for some.

With Eric's permission.......

"To be more explicit about what was happening....

We were redirecting accesses to *.exe and *.dll in our download directory from boinc2.ssl.berkeley.edu to boinc2.ssl.berkeley.edu.nyud.net which should provide a cached copy. There are two potential problems with this, some firewalls consider redirecting to be a security risk so they refuse to allow the connection, and some DNS services don't properly resolve nyud.net addresses. Unfortunately when we release a new version, the advantage of still having functional download servers outweighs the disadvantage.

I've removed the redirects from georgem, but still have them on on vader."

So, there's the nuts and bolts of why Coral Cache was giving some of us fits trying to get our new apps downloaded.

Meow, and away!

---

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

There seems to be a bit of a problem with cuda22 and cuda23 work finishing in errors on other rigs, an example http://setiathome.berkeley.edu/workunit.php?wuid=1256169015, and those pesky GTX 560Ti's are still doing their thing.

Also my 1st inconclusive, http://setiathome.berkeley.edu/workunit.php?wuid=1256474447. :-(

Cheers.

There seems to be a bit of a problem with cuda22 and cuda23 work finishing in errors on other rigs, an example http://setiathome.berkeley.edu/workunit.php?wuid=1256169015, and those pesky GTX 560Ti's are still doing their thing.

Were those rigs producing errors previously?

Also my 1st inconclusive, http://setiathome.berkeley.edu/workunit.php?wuid=1256474447. :-(

Interesting that one- only difference between the SETI@home v7 v7.00 (cuda42) & SETI@home v7 Anonymous platform (NVIDIA GPU) results is that one was done using an anonymous plaform setup, and the systems had different video cards & different drivers. But both were running the same application, and it configured itself the same way on both systems for processing.


EDT- just had a look at my inconclusives- and they're mostly Cuda50s not validating against opencl_ati_sah with a few Cuda42/32 etc types in the mix- but 90%+ are opencl_ati_sah results.

---

Grant
Darwin NT

You would need, as a minimum,

http://boinc2.ssl.berkeley.edu/sah/download_fanout/setiathome_7.00_windows_intelx86.exe
http://boinc2.ssl.berkeley.edu/sah/download_fanout/libfftw3f-3-3_upx.dll

I've deliberately not made them clickable, because I want casual readers to stop and think before downloading.

The file sizes are 484,352 and 1,049,920 bytes respectively. Internet Explorer seems to have a habit of truncating manual downloads: Chrome seems better.

I was a bit late in noticing that the new v7 has been released. Is the file compatible with AMD CPU's, as it explicitly mentions intelx86 in the name?

I guess the following changes would be sufficient for the app_info file

    <app>
        <name>setiathome_v7</name>
    </app>
    <file_info>
        <name>setiathome_7.00_windows_intelx86.exe</name>
        <executable/>
    </file_info>
    <file_info>
        <name>libfftw3f-3-3_upx.dll</name>
        <executable/>
    </file_info>
    <app_version>
        <app_name>setiathome_v7</app_name>
        <version_num>700</version_num>
	<platform>windows_intelx86</platform>
        <file_ref>
            <file_name>setiathome_7.00_windows_intelx86.exe</file_name>
            <main_program/>
        </file_ref>
    </app_version>

that's missing

        <file_ref>
            <file_name>libfftw3f-3-3_upx.dll</file_name>
        </file_ref>

before the </appversion>

---

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

There seems to be a bit of a problem with cuda22 and cuda23 work finishing in errors on other rigs, an example http://setiathome.berkeley.edu/workunit.php?wuid=1256169015, and those pesky GTX 560Ti's are still doing their thing.

Also my 1st inconclusive, http://setiathome.berkeley.edu/workunit.php?wuid=1256474447. :-(

Cheers.

Thanks, The Cuda22/23 examples show as very early 'Too Many Exit(0)s', which tends to indicate Boinc temporary exits for any number of reasons, before the app even starts up. They'll be skunted off to 1 task per day (per app) land :D, looks like the driver is so old that they won't even get Cuda32.

As for the problem 560ti, looks like the validator doing its job there. The Ati host there I believe (with limited knowledge on the issue) is running insufficient SDK, might be a more serious situation, though I don't know the details.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Have now taken to manually aborting:
-AP WUs on non AVX machines
-v7 cuda50 WUs on all machines
-v7 cuda23 WUs on all GTX580 based machines

If you do that you'll never get APR to settle and scheduler select 'fastest' app. If it's an intermediate measure until you go anon again...

---

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

EDT- just had a look at my inconclusives- and they're mostly Cuda50s not validating against opencl_ati_sah with a few Cuda42/32 etc types in the mix- but 90%+ are opencl_ati_sah results.

hmmm, looks like the same ati sitation.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

There seems to be a bit of a problem with cuda22 and cuda23 work finishing in errors on other rigs, an example http://setiathome.berkeley.edu/workunit.php?wuid=1256169015, and those pesky GTX 560Ti's are still doing their thing.

Were those rigs producing errors previously?

They don't look to have been.

Also my 1st inconclusive, http://setiathome.berkeley.edu/workunit.php?wuid=1256474447. :-(

Interesting that one- only difference between the SETI@home v7 v7.00 (cuda42) & SETI@home v7 Anonymous platform (NVIDIA GPU) results is that one was done using an anonymous plaform setup, and the systems had different video cards & different drivers. But both were running the same application, and it configured itself the same way on both systems for processing.


EDT- just had a look at my inconclusives- and they're mostly Cuda50s not validating against opencl_ati_sah with a few Cuda42/32 etc types in the mix- but 90%+ are opencl_ati_sah results.

The 560Ti in that inconclusive has been a very long term horrid rig but the other was fine until V7. ;-(

Cheers.

There seems to be a bit of a problem with cuda22 and cuda23 work finishing in errors on other rigs, an example http://setiathome.berkeley.edu/workunit.php?wuid=1256169015, and those pesky GTX 560Ti's are still doing their thing.

Also my 1st inconclusive, http://setiathome.berkeley.edu/workunit.php?wuid=1256474447. :-(

Cheers.

Thanks, The Cuda22/23 examples show as very early 'Too Many Exit(0)s', which tends to indicate Boinc temporary exits for any number of reasons, before the app even starts up. They'll be skunted off to 1 task per day (per app) land :D, looks like the driver is so old that they won't even get Cuda32.

Now you can ponder whether it's good that the infinite loop on temporary exits that I bugrepped got fixed, or whether it would be preferable the machine choked and got the next full chache after timeout...

As for the problem 560ti, looks like the validator doing its job there. The Ati host there I believe (with limited knowledge on the issue) is running insufficient SDK, might be a more serious situation, though I don't know the details.

Responsability of the other part of the team.
I think I saw a bugrep (to Eric) somewhere in the Chaos and Mayhem, so it's being looked into.

---

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

EDT- just had a look at my inconclusives- and they're mostly Cuda50s not validating against opencl_ati_sah with a few Cuda42/32 etc types in the mix- but 90%+ are opencl_ati_sah results.

hmmm, looks like the same ati sitation.

Just had a further look at my inconclusives.
One V7 Cuda42 v a V7 v7.00 inconclusive.
The others were a v7.00 & a Cuda42 coming up inconclusive against opencl_ati5_sah results.




EDIT- for those that are interested.

Of 20 v7 inconclusives, 18 of them are against a v7 opencl_ati_ of one type or another.

---

Grant
Darwin NT

Claggy

Don't think so mate.

At the moment things seem to be running wellish. Over the last 2.5 hours I have only received 3 x cuda50 GPU WUs, and 2 x AP WUs on boxes that I don't want AP on. All were aborted.

See my advice to use 'venues' in response to another post of yours.

I will say something though that I think you should look at.

The limiting of the GPU allocation to 0.02 CPUs or 0.03 CPUs has the effect of nobbling the GPU. The limit should be upwards of 0.10 CPU (I ran my boxes at 0.20 CPU per GPU prior to v7 migration).

What this does is to ensure that the GPU gets the resources it needs when it needs them. In observing my systems, I have seen utilisation regularly jump to 0.07 - 0.14. In using 0.20 CPUs, it doesn't mean that it has 0.20 CPUs allocated permanently to the GPU. If the GPU isn't using it, then the processor will. It's just an allocation of resource issue that keeps the GPUs munching as fast as they can.

You misunderstand what the 0.02, or 0.10, or whatever means or does.

It does not limit CPU usage.

It controls BOINC's scheduling. If you run 50 GPU tasks at once (first figure), or 10 GPU tasks at once (second figure), the CPU bits will add up to a whole 1.00 CPU, and BOINC will stop running one CPU task (will run one fewer CPU task than normal). That's all.

The 0.02 figure is one we've been putting in published and distributed app_info files (e.g. via the installer) for years. Basically, it stops the CPU application count jumping all over the place. NVidia applications are normally happy to run even when every CPU core has a BOINC task running on it (ATI experience may be different). If your experience is different - say for a host with more than one high-power GPU, but a weak CPU, which I would call an unbalanced build - reduce the active CPU count yourself by adjusting the

On multiprocessors, use at most 
Enforced by version 6.1+	100% of the processors

for the venue that host is assigned to.

I think the kitties have gone all stock until the new installer rolls out.

Many others might be induced to do as well.

It won't do any good to continue to wank those that need to spend their time writing installer code rather than to ask repetitive questions here.

Meow, and goodnight.

---

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

I think the kitties have gone all stock until the new installer rolls out.

Many others might be induced to do as well.

It won't do any good to continue to wank those that need to spend their time writing installer code rather than to ask repetitive questions here.

Meow, and goodnight.

Yes I better stop reading NC and trying to answer the same silly question for the 15th time, or we won't be able to hold the Monday deadline.

It's been said that out of the three things money, time and quality only two can be achieved. Since we don;t get any money two remain, out of which one can be achibved. Guess.

Over and out.

---

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

Yes I better stop reading NC and trying to answer the same silly question for the 15th time, or we won't be able to hold the Monday deadline.

I'd suggest the Monday after next would be a better target.

With a week of people running stock (or not at all) the auto application optimisation selection should have had a chance to do it's thing & things should be settled down, somewhat.

---

Grant
Darwin NT

that's missing

        <file_ref>
            <file_name>libfftw3f-3-3_upx.dll</file_name>
        </file_ref>

before the </appversion>

Thanks for pointing that out William.
______________