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

When I checked, you were aborting v7 cuda23 tasks on your GTX 295 host, not your GTX580 hosts, and if you were then there would be a scheduler Bug because the Cuda23 Can't be run on Fermi's and Keplers.

Claggy

Before we switched to v7 we had a shorties storm, is that one still raging in v7?

Hadn't noticed anything before the outage.
Till i can get these executables to download no way of knowing myself- i doubt it as the splitters don't apear to be splitting much, and there's no ready-to-send buffer.

The Server Status Page section on Database/File Status does not yet reflect V7 task generation, only Enhanced V6, which are no longer being split. We saw the same thing when they rolled out Astropulse V6. Until almost all S@H V6 work is returned and validated, they will not change the display to reflect V7 production.

Looks like they went ahead and updated the Server Status Page so the Splitter Status Table reflects V7 production. That will make a few people less unhappy.

---

Donald
Infernal Optimist / Submariner, retired

Vic wrote:
]

I'm just having a large missed deadline v7 gpu wu's, yet no deadline that I looked at is earlier than 6/19/2013, I used to get the occasional one under v6, but that was it. Why?

SETI@home 7.00 setiathome_v7 (cuda42) 26jn12ab.17393.3343.15.12.234_1 00:14:31 (00:02:10) 5/30/2013 3:43:49 PM 5/30/2013 3:43:49 PM 0.05C + 0.5NV 14.93 Missed
SETI@home 7.00 setiathome_v7 (cuda42) 26mr10ab.31337.1466.10.12.214_3 00:17:33 (00:02:13) 5/30/2013 3:36:37 PM 5/30/2013 3:36:37 PM 0.05C + 0.5NV 12.63 Missed
SETI@home 7.00 setiathome_v7 (cuda42) 26mr10ab.16506.4979.13.12.200_0 00:17:54 (00:02:16) 5/30/2013 3:25:47 PM 5/30/2013 3:29:09 PM 0.05C + 0.5NV 12.66 Reported: OK

Looks like a BoincTasks History tab. The "missed" doesn't refer to deadline, just that BoincTasks missed picking up the information when BOINC reported the task completion. You'll probably find those tasks in your pendings or validated - you don't show any expired for deadlines. Don't know why BT is missing so many. it always misses a few a day but this is unusual. I haven't had that problem with my first 100 V7 tasks and BT 1.46, so if it continues, take it up with Fred in his forum.

---

Another Fred
Support SETI@home when you search the Web with GoodSearch or shop online with GoodShop.

Well I wasn't going to do anything until next week, but I got bored.

The GTX 550Ti's on my 2500K are now running V7 and so far so good.

If it stays that way then tomorrow or the day after I'll do the same with the GTX 660's on my Q6600.

Cheers.

Well I wasn't going to do anything until next week, but I got bored.

The GTX 550Ti's on my 2500K are now running V7 and so far so good.

If it stays that way then tomorrow or the day after I'll do the same with the GTX 660's on my Q6600.

Cheers.

Enjoy the ride ...

L.

---

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

When I checked, you were aborting v7 cuda23 tasks on your GTX 295 host, not your GTX580 hosts, and if you were then there would be a scheduler Bug because the Cuda23 Can't be run on Fermi's and Keplers.

Claggy

Richard, Claggy

AP:
I only run AP on the i7 with the CPU. I don't run AP on the GPUs in this box and I don't run AP on any of the other boxes (CPU or GPU).

MB:
v7 cuda50 was taking circa 80 minutes to run on the 295s. Far to long, so any cuda50 WUs landing here get aborted.

v7 cuda50 wus landing on any of the 580s also get aborted. The ones that have landed here and I have seen seem to have an exponential processing time albiet not as bad as the 295s. I must say that since implementing this practice the number of cuda50 WUs landing on these GPUs is declining to almost being non existent.

v7 cuda23 wus landed on the Q6600 with dual GTX580s. These appeared to be going down the same path as the cuda50 so they were aborted.

The 295s are now running cuda32 and cuda42 WUs for the GPU.
One of the 580s is running only cuda42 WUs at present, the other is running cuda32 and cuda42 WUs at present (just burnt another cuda50 WU there).

---

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

When I checked, you were aborting v7 cuda23 tasks on your GTX 295 host, not your GTX580 hosts, and if you were then there would be a scheduler Bug because the Cuda23 Can't be run on Fermi's and Keplers.

Claggy

Richard, Claggy

AP:
I only run AP on the i7 with the CPU. I don't run AP on the GPUs in this box and I don't run AP on any of the other boxes (CPU or GPU).

MB:
v7 cuda50 was taking circa 80 minutes to run on the 295s. Far to long, so any cuda50 WUs landing here get aborted.

v7 cuda50 wus landing on any of the 580s also get aborted. The ones that have landed here and I have seen seem to have an exponential processing time albiet not as bad as the 295s. I must say that since implementing this practice the number of cuda50 WUs landing on these GPUs is declining to almost being non existent.

v7 cuda23 wus landed on the Q6600 with dual GTX580s. These appeared to be going down the same path as the cuda50 so they were aborted.

The 295s are now running cuda32 and cuda42 WUs for the GPU.
One of the 580s is running only cuda42 WUs at present, the other is running cuda32 and cuda42 WUs at present (just burnt another cuda50 WU there).

Let the different Cuda version tasks complete, the progress indication on v7 isn't Linear, there is speedup over the second half, let the different Cuda versions tasks complete, then the scheduler will pick the fastest version, at the moment you're prolonging it,

Claggy

Isn't is possible to download stock v7 CPU app and put it in app_info.xml ?

sure it's possible.
We just hope to provide faster app at Monday.
For now stock v7 CPU could go.

What's the URL for stock app then? (until monday)

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.

Thanks works fine it seems. DL with Chrome with no probs.

Could you, or someone other post the app_info.xml file entries part for stock SAHv7 CPU app?

Thanks.


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

---

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.