Now that v7 has rolled out..........

Message boards : Number crunching : Now that v7 has rolled out..........
Message board moderation

To post messages, you must log in.

Previous · 1 . . . 10 · 11 · 12 · 13 · 14 · 15 · 16 . . . 17 · Next

AuthorMessage
Profile Wiggo
Avatar

Send message
Joined: 24 Jan 00
Posts: 37379
Credit: 261,360,520
RAC: 489
Australia
Message 1374115 - Posted: 31 May 2013, 8:47:31 UTC - in response to Message 1374097.  

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.
ID: 1374115 · Report as offensive
Profile William
Volunteer tester
Avatar

Send message
Joined: 14 Feb 13
Posts: 2037
Credit: 17,689,662
RAC: 0
Message 1374116 - Posted: 31 May 2013, 8:47:46 UTC - in response to Message 1374111.  

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)
ID: 1374116 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13886
Credit: 208,696,464
RAC: 304
Australia
Message 1374118 - Posted: 31 May 2013, 8:49:47 UTC - in response to Message 1374113.  
Last modified: 31 May 2013, 8:56:46 UTC

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
ID: 1374118 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14688
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1374122 - Posted: 31 May 2013, 8:52:10 UTC - in response to Message 1374022.  

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.
ID: 1374122 · Report as offensive
kittyman Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Jul 00
Posts: 51511
Credit: 1,018,363,574
RAC: 1,004
United States
Message 1374124 - Posted: 31 May 2013, 8:55:50 UTC
Last modified: 31 May 2013, 8:56:52 UTC

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."

ID: 1374124 · Report as offensive
Profile William
Volunteer tester
Avatar

Send message
Joined: 14 Feb 13
Posts: 2037
Credit: 17,689,662
RAC: 0
Message 1374127 - Posted: 31 May 2013, 9:01:32 UTC - in response to Message 1374124.  

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)
ID: 1374127 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13886
Credit: 208,696,464
RAC: 304
Australia
Message 1374128 - Posted: 31 May 2013, 9:04:43 UTC - in response to Message 1374127.  

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
ID: 1374128 · Report as offensive
Profile Vipin Palazhi
Avatar

Send message
Joined: 29 Feb 08
Posts: 286
Credit: 167,386,578
RAC: 0
India
Message 1374139 - Posted: 31 May 2013, 9:35:37 UTC - in response to Message 1374109.  


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.
______________

ID: 1374139 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13886
Credit: 208,696,464
RAC: 304
Australia
Message 1374154 - Posted: 31 May 2013, 9:57:28 UTC - in response to Message 1374118.  

EDIT- for those that are interested.

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



Just got some more inconlusives, however these are Cuda50 v other Cuda applications.
One of which involves 2 GTX 560Ti's.

setiathome enhanced x41zc, Cuda 3.20 (314.22 driver)
Spike count: 0
Autocorr count: 2
Pulse count: 0
Triplet count: 1
Gaussian count: 0


setiathome enhanced x41zc, Cuda 5.00 (320.18 driver)
Spike count: 1
Autocorr count: 2
Pulse count: 0
Triplet count: 1
Gaussian count: 0
Grant
Darwin NT
ID: 1374154 · Report as offensive
MikeN

Send message
Joined: 24 Jan 11
Posts: 319
Credit: 64,719,409
RAC: 85
United Kingdom
Message 1374156 - Posted: 31 May 2013, 10:01:21 UTC

Now that my GTX460 cruncher is on stock app for the first time, it downloaded its first Nvidea AP to crunch using opencl. However, GPU utilization is very low. For MB WUs, GPU utilization is typically 80-90% (for 1 v7 WU), but the AP was only showing ca 4% GPU utilization. I freed up one CPU core and this increased to 18% with occaisional bursts up to 100%. Freeing up a second CPU core made no difference. Is this normal?

The AP WU is currently 24% complete and has been running for 1.5 hours, so it is heading for about 6 hours to complete. Does this sound right for a GTX460 running at 857MHz?
ID: 1374156 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14688
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1374157 - Posted: 31 May 2013, 10:05:42 UTC - in response to Message 1374156.  

Now that my GTX460 cruncher is on stock app for the first time, it downloaded its first Nvidea AP to crunch using opencl. However, GPU utilization is very low. For MB WUs, GPU utilization is typically 80-90% (for 1 v7 WU), but the AP was only showing ca 4% GPU utilization. I freed up one CPU core and this increased to 18% with occaisional bursts up to 100%. Freeing up a second CPU core made no difference. Is this normal?

The AP WU is currently 24% complete and has been running for 1.5 hours, so it is heading for about 6 hours to complete. Does this sound right for a GTX460 running at 857MHz?

Freeing a core (just one for one card) for OpenCL is normal, yes. Can't comment on timings, I'll leave that for the OpenCL specialists.
ID: 1374157 · Report as offensive
Lionel

Send message
Joined: 25 Mar 00
Posts: 680
Credit: 563,640,304
RAC: 597
Australia
Message 1374175 - Posted: 31 May 2013, 10:45:11 UTC - in response to Message 1374112.  

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...


William,

Doesn't appear to be the case. Aborting them is working quite well. The appearances of cuda50 and cuda23 WU is now almost non existent. Haven't had a cuda23 WU in ages ... and cuda50 is now only popping up once in a blue moon ... seems to work better than processing the WUs ... would recommend this approach to anyone to try

:)
ID: 1374175 · Report as offensive
Lionel

Send message
Joined: 25 Mar 00
Posts: 680
Credit: 563,640,304
RAC: 597
Australia
Message 1374181 - Posted: 31 May 2013, 10:56:32 UTC - in response to Message 1374122.  

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.


Yep, I'm aware of that ...

The 0.02 figure is one we've been putting in published and distributed app_info files (e.g. via the installer) for years.


Yep, I'm aware of that too...


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.


Yep, tried reducing active CPUs as well ...

Best results obtained by changing 0.02 CPU to 0.20 CPU. In doing this, RAC increased to highest levels of all configurations that I tried. QED in my case. Have a look at Smallpox, it's an i7 3930K with 2 x GTX580s (ranked around #13). You would have to say that it's a bloody good performer wouldn't you given the GPU tech.

cheers mate ...

ps. that is before v7 migration which throws some uncertainty into the mix.







ID: 1374181 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14688
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1374189 - Posted: 31 May 2013, 11:08:23 UTC - in response to Message 1374181.  

Best results obtained by changing 0.02 CPU to 0.20 CPU. In doing this, RAC increased to highest levels of all configurations that I tried. QED in my case. Have a look at Smallpox, it's an i7 3930K with 2 x GTX580s (ranked around #13). You would have to say that it's a bloody good performer wouldn't you given the GPU tech.

How exactly do you attribute effect to cause, with that one?

I'm genuinely interested, but sceptical. If there's a real relationship (both demonstratable and explicable, scientifically), then we ought to change the installer we're writing.
ID: 1374189 · Report as offensive
Profile William
Volunteer tester
Avatar

Send message
Joined: 14 Feb 13
Posts: 2037
Credit: 17,689,662
RAC: 0
Message 1374191 - Posted: 31 May 2013, 11:09:09 UTC - in response to Message 1374175.  
Last modified: 31 May 2013, 11:11:22 UTC

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...


William,

Doesn't appear to be the case. Aborting them is working quite well. The appearances of cuda50 and cuda23 WU is now almost non existent. Haven't had a cuda23 WU in ages ... and cuda50 is now only popping up once in a blue moon ... seems to work better than processing the WUs ... would recommend this approach to anyone to try

:)

That is because aborts count as errors against your quota.

edit: I suggest to let at least a few through, slow as they might be.
A person who won't read has no advantage over one who can't read. (Mark Twain)
ID: 1374191 · Report as offensive
Lionel

Send message
Joined: 25 Mar 00
Posts: 680
Credit: 563,640,304
RAC: 597
Australia
Message 1374197 - Posted: 31 May 2013, 11:22:40 UTC - in response to Message 1374189.  

Best results obtained by changing 0.02 CPU to 0.20 CPU. In doing this, RAC increased to highest levels of all configurations that I tried. QED in my case. Have a look at Smallpox, it's an i7 3930K with 2 x GTX580s (ranked around #13). You would have to say that it's a bloody good performer wouldn't you given the GPU tech.

How exactly do you attribute effect to cause, with that one?

I'm genuinely interested, but sceptical. If there's a real relationship (both demonstratable and explicable, scientifically), then we ought to change the installer we're writing.


Richard, I have changed things at my end over time and watched the results. In essence I do not care if you do not believe me or do not want to take what I say at face value. That is your choice and I accept it. I can only speak from my experience and my experience with these machines tells me that 0.03 CPU or something similar reduces processing capabilities for the GPUs ... after a particular value it becomes irrelevant however I chose to set it higher than needed.

When the optimised installer comes out and I will once again be able to set up the system to the manner I like, I will revert to 0.20 CPU and then experiment for myself from there.

cheers


ID: 1374197 · Report as offensive
Lionel

Send message
Joined: 25 Mar 00
Posts: 680
Credit: 563,640,304
RAC: 597
Australia
Message 1374198 - Posted: 31 May 2013, 11:23:33 UTC - in response to Message 1374191.  


William, ain't going to happen pal
ID: 1374198 · Report as offensive
Profile Dirk Sadowski
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 1374202 - Posted: 31 May 2013, 11:44:55 UTC
Last modified: 31 May 2013, 12:17:02 UTC

It looks like to now noone posted a complete app_info.xml part for stock SAHv7 CPU app, or?

I made one (for 64bit OS), please let me know if it's OK or wrong. [EDIT: It's OK, thanks William.]

    <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>
        <file_ref>
	    <file_name>libfftw3f-3-3_upx.dll</file_name>
        </file_ref>
     </app_version>
     <app_version>
        <app_name>setiathome_v7</app_name>
        <version_num>700</version_num>
         <platform>windows_x86_64</platform>
          <file_ref>
            <file_name>setiathome_7.00_windows_intelx86.exe</file_name>
            <main_program/>
         </file_ref>
        <file_ref>
	    <file_name>libfftw3f-3-3_upx.dll</file_name>
        </file_ref>
     </app_version>


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


* Best regards! :-) * Philip J. Fry, team seti.international founder. * Optimize your PC for higher RAC. * SETI@home needs your help. *
ID: 1374202 · Report as offensive
Profile William
Volunteer tester
Avatar

Send message
Joined: 14 Feb 13
Posts: 2037
Credit: 17,689,662
RAC: 0
Message 1374206 - Posted: 31 May 2013, 12:03:11 UTC - in response to Message 1374202.  

It looks like to now noone posted a complete app_info.xml part for stock SAHv7 CPU app, or?

I made one (for 64bit OS), please let me know if it's OK or wrong.

looks good
A person who won't read has no advantage over one who can't read. (Mark Twain)
ID: 1374206 · Report as offensive
MikeN

Send message
Joined: 24 Jan 11
Posts: 319
Credit: 64,719,409
RAC: 85
United Kingdom
Message 1374210 - Posted: 31 May 2013, 12:16:19 UTC - in response to Message 1374157.  

Now that my GTX460 cruncher is on stock app for the first time, it downloaded its first Nvidea AP to crunch using opencl. However, GPU utilization is very low. For MB WUs, GPU utilization is typically 80-90% (for 1 v7 WU), but the AP was only showing ca 4% GPU utilization. I freed up one CPU core and this increased to 18% with occaisional bursts up to 100%. Freeing up a second CPU core made no difference. Is this normal?

The AP WU is currently 24% complete and has been running for 1.5 hours, so it is heading for about 6 hours to complete. Does this sound right for a GTX460 running at 857MHz?

Freeing a core (just one for one card) for OpenCL is normal, yes. Can't comment on timings, I'll leave that for the OpenCL specialists.


Thanks Richard.

In the end it finished normally in 3.5 hours. Is there a clever way of freeing up one CPU core when the GPU is running an AP but when it is running MBs which do not need it? I do not want to loose 25% of my CPU RAC and cannot lways be present to baby sit the machine.

Not sure why the apparent GPU usage was so low, but it has returned to 70-80% now that the GPU is cruching MBs again.

ID: 1374210 · Report as offensive
Previous · 1 . . . 10 · 11 · 12 · 13 · 14 · 15 · 16 . . . 17 · Next

Message boards : Number crunching : Now that v7 has rolled out..........


 
©2025 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.