the latest on release of AP_v7?

Message boards : Number crunching : the latest on release of AP_v7?
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3

AuthorMessage
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 1575392 - Posted: 21 Sep 2014, 4:52:40 UTC
Last modified: 21 Sep 2014, 5:08:34 UTC

It looks like some members didn't understood this thread correct ...

Currently the APv7 apps are for SETI BETA.

Currently it's not OK to use this apps here at SETI Main (with APv6 WUs).
Look at your host overview -> invalid results.

Maybe an official statement of Raistmer needed? ;-)
ID: 1575392 · Report as offensive
qbit
Volunteer tester
Avatar

Send message
Joined: 19 Sep 04
Posts: 630
Credit: 6,868,528
RAC: 0
Austria
Message 1575418 - Posted: 21 Sep 2014, 6:22:43 UTC
Last modified: 21 Sep 2014, 6:23:32 UTC

@TBar @ Dirk: Yeah, I know, but I had to try because I wanted to know if my computer still has the occasional crashes with V7. Well, he crashed again 2 hours ago, so I guess I have my answer. Going back to V6 now, too many inconclusive/invalid results here already. Looks like the validators are not tuned for V7 yet.
ID: 1575418 · Report as offensive
Claggy
Volunteer tester

Send message
Joined: 5 Jul 99
Posts: 4654
Credit: 47,537,079
RAC: 4
United Kingdom
Message 1575458 - Posted: 21 Sep 2014, 8:09:22 UTC - in response to Message 1575379.  
Last modified: 21 Sep 2014, 8:22:46 UTC

AFAIK from Raistmer the 'rule of thumb', the -ffa_block & -ffa_block_fetch values for APv6 is to take /2 for APv7.

No, the rule of thumb was to halve them for TWIN FFA apps, APv6 has TWIN FFA apps too.

For APv6, (in the Lunatics 0.41 Installer)

AP6_win_x86_SSE2_OpenCL_ATI_r1843.exe and AP6_win_x86_SSE2_OpenCL_NV_r1843.exe are Single FFA:

Build features: Non-graphics OpenCL USE_OPENCL_NV OCL_ZERO_COPY COMBINED_DECHIRP_KERNEL FFTW USE_INCREASED_PRECISION USE_SSE2 x86
CPUID: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz

Cache: L1=64K L2=4096K

CPU features: FPU TSC PAE CMPXCHG8B APIC SYSENTER MTRR CMOV/CCMP MMX FXSAVE/FXRSTOR SSE SSE2 HT SSE3 SSSE3
AstroPulse v6
Non-graphics FFTW USE_CONVERSION_OPT
Windows x86 rev 1843, V6 match, by Raistmer with support of Lunatics.kwsn.net team. SSE2


For APv6, (in the Lunatics 0.42 Installer)

AP6_win_x86_SSE2_OpenCL_ATI_r2399.exe and AP6_win_x86_SSE2_OpenCL_NV_r2399.exe are TWIN_FFA:

Build features: Non-graphics OpenCL USE_OPENCL_NV TWIN_FFA OCL_ZERO_COPY COMBINED_DECHIRP_KERNEL FFTW USE_INCREASED_PRECISION USE_SSE2 x86
CPUID: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz

Cache: L1=64K L2=256K

CPU features: FPU TSC PAE CMPXCHG8B APIC SYSENTER MTRR CMOV/CCMP MMX FXSAVE/FXRSTOR SSE SSE2 HT SSE3 SSSE3 SSE4.1 SSE4.2 AVX
AstroPulse v6 Windows x86 rev 2399, V6 match, by Raistmer with support of Lunatics.kwsn.net team. SSE2


For APv7, Both Stock and Optimised APv7 are TWIN_FFA:

Build features: Non-graphics BLANKIT OpenCL USE_OPENCL_NV TWIN_FFA OCL_ZERO_COPY COMBINED_DECHIRP_KERNEL FFTW USE_INCREASED_PRECISION USE_SSE2 x86
CPUID: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz

Cache: L1=64K L2=256K

CPU features: FPU TSC PAE CMPXCHG8B APIC SYSENTER MTRR CMOV/CCMP MMX FXSAVE/FXRSTOR SSE SSE2 HT SSE3 SSSE3 SSE4.1 SSE4.2 AVX
AstroPulse v7 Windows x86 rev 2690, V7 match, by Raistmer with support of Lunatics.kwsn.net team. SSE2


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

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1575490 - Posted: 21 Sep 2014, 9:09:45 UTC - in response to Message 1575418.  

@TBar @ Dirk: Yeah, I know, but I had to try because I wanted to know if my computer still has the occasional crashes with V7. Well, he crashed again 2 hours ago, so I guess I have my answer. Going back to V6 now, too many inconclusive/invalid results here already. Looks like the validators are not tuned for V7 yet.

No validator tuning is required, or will be applied. All the validator does is to compare two (sometimes more) results. If it is asked to compare a v6 result with a v7 result, the likelihood is that it will declare them different - unless there are no signals to be found in the data.

You will be getting inconclusive/invalid results because your results are different from those returned by other users still - and properly - running the v6 app. Wait until the full release takes place for everybody before you use a v7 app here. If you want to test whether the v7 app crashes on your computer, use the Beta site - that's what it's there for.
ID: 1575490 · Report as offensive
merle van osdol

Send message
Joined: 23 Oct 02
Posts: 809
Credit: 1,980,117
RAC: 0
United States
Message 1575494 - Posted: 21 Sep 2014, 9:21:10 UTC

Zalster,

Sorry about your stir-fry.

Always something for life to struggle with.
ID: 1575494 · Report as offensive
qbit
Volunteer tester
Avatar

Send message
Joined: 19 Sep 04
Posts: 630
Credit: 6,868,528
RAC: 0
Austria
Message 1575502 - Posted: 21 Sep 2014, 9:35:16 UTC - in response to Message 1575490.  

@TBar @ Dirk: Yeah, I know, but I had to try because I wanted to know if my computer still has the occasional crashes with V7. Well, he crashed again 2 hours ago, so I guess I have my answer. Going back to V6 now, too many inconclusive/invalid results here already. Looks like the validators are not tuned for V7 yet.

No validator tuning is required, or will be applied. All the validator does is to compare two (sometimes more) results. If it is asked to compare a v6 result with a v7 result, the likelihood is that it will declare them different - unless there are no signals to be found in the data.

You will be getting inconclusive/invalid results because your results are different from those returned by other users still - and properly - running the v6 app. Wait until the full release takes place for everybody before you use a v7 app here. If you want to test whether the v7 app crashes on your computer, use the Beta site - that's what it's there for.

Thx once again for the explanation, Richard!
Somebody else told me that the validators have to be tuned for v7 because signals found within blanking are interpreted differently on v7 then they were on v6.
I guess I should really learn a bit more about MB/AP because until now I don't really know how exactly this all works and what exactly the apps are doing when crunching a task. Problem is that all those scientific things can be a bit hard to understand when english isn't your main language.
Anyway, as I said, I'm back at v6 now and will wait for official release. And BTW, I wanted to test on Beta first but somethings different there. When I started the AP task it was using more then 60% CPU!?! I never saw something like that here on main, so I deceided to test the beta apps here.
ID: 1575502 · Report as offensive
Claggy
Volunteer tester

Send message
Joined: 5 Jul 99
Posts: 4654
Credit: 47,537,079
RAC: 4
United Kingdom
Message 1575523 - Posted: 21 Sep 2014, 11:12:49 UTC - in response to Message 1575502.  
Last modified: 21 Sep 2014, 11:14:04 UTC

When I started the AP task it was using more then 60% CPU!?! I never saw something like that here on main, so I deceided to test the beta apps here

All Nvidia drivers since 27x.xx have suffered from the Nvidia OpenCL 100% CPU Usage feature/Bug, 337.88 is no exception.

You're using -use_sleep at the Main project, did you put put it in your ap_cmdline.txt file for NV 7.04? If you didn't, then you'll get high CPU usage.

Claggy
ID: 1575523 · Report as offensive
Profile Sutaru Tsureku
Volunteer tester

Send message
Joined: 6 Apr 07
Posts: 7105
Credit: 147,663,825
RAC: 5
Germany
Message 1575662 - Posted: 21 Sep 2014, 17:57:42 UTC - in response to Message 1575458.  
Last modified: 21 Sep 2014, 18:04:24 UTC

AFAIK from Raistmer the 'rule of thumb', the -ffa_block & -ffa_block_fetch values for APv6 is to take /2 for APv7.

No, the rule of thumb was to halve them for TWIN FFA apps, APv6 has TWIN FFA apps too.

For APv6, (in the Lunatics 0.41 Installer)

AP6_win_x86_SSE2_OpenCL_ATI_r1843.exe and AP6_win_x86_SSE2_OpenCL_NV_r1843.exe are Single FFA:

Build features: Non-graphics OpenCL USE_OPENCL_NV OCL_ZERO_COPY COMBINED_DECHIRP_KERNEL FFTW USE_INCREASED_PRECISION USE_SSE2 x86
CPUID: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz

Cache: L1=64K L2=4096K

CPU features: FPU TSC PAE CMPXCHG8B APIC SYSENTER MTRR CMOV/CCMP MMX FXSAVE/FXRSTOR SSE SSE2 HT SSE3 SSSE3
AstroPulse v6
Non-graphics FFTW USE_CONVERSION_OPT
Windows x86 rev 1843, V6 match, by Raistmer with support of Lunatics.kwsn.net team. SSE2


For APv6, (in the Lunatics 0.42 Installer)

AP6_win_x86_SSE2_OpenCL_ATI_r2399.exe and AP6_win_x86_SSE2_OpenCL_NV_r2399.exe are TWIN_FFA:

Build features: Non-graphics OpenCL USE_OPENCL_NV TWIN_FFA OCL_ZERO_COPY COMBINED_DECHIRP_KERNEL FFTW USE_INCREASED_PRECISION USE_SSE2 x86
CPUID: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz

Cache: L1=64K L2=256K

CPU features: FPU TSC PAE CMPXCHG8B APIC SYSENTER MTRR CMOV/CCMP MMX FXSAVE/FXRSTOR SSE SSE2 HT SSE3 SSSE3 SSE4.1 SSE4.2 AVX
AstroPulse v6 Windows x86 rev 2399, V6 match, by Raistmer with support of Lunatics.kwsn.net team. SSE2


For APv7, Both Stock and Optimised APv7 are TWIN_FFA:

Build features: Non-graphics BLANKIT OpenCL USE_OPENCL_NV TWIN_FFA OCL_ZERO_COPY COMBINED_DECHIRP_KERNEL FFTW USE_INCREASED_PRECISION USE_SSE2 x86
CPUID: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz

Cache: L1=64K L2=256K

CPU features: FPU TSC PAE CMPXCHG8B APIC SYSENTER MTRR CMOV/CCMP MMX FXSAVE/FXRSTOR SSE SSE2 HT SSE3 SSSE3 SSE4.1 SSE4.2 AVX
AstroPulse v7 Windows x86 rev 2690, V7 match, by Raistmer with support of Lunatics.kwsn.net team. SSE2


Claggy

From where I could know it that r2399 already have TWIN_FFA - and what this means?
(-> values /2 for -ffa_block & -ffa_block_fetch)

In the 'Lunatics Windows Installer v0.42 Release Notes' thread »here« in the opening message I couldn't read it.

Or where is this interesting info available?
ID: 1575662 · Report as offensive
Claggy
Volunteer tester

Send message
Joined: 5 Jul 99
Posts: 4654
Credit: 47,537,079
RAC: 4
United Kingdom
Message 1575668 - Posted: 21 Sep 2014, 18:14:01 UTC - in response to Message 1575662.  

From where I could know it that r2399 already have TWIN_FFA - and what this means?
(-> values /2 for -ffa_block & -ffa_block_fetch)

In the 'Lunatics Windows Installer v0.42 Release Notes' thread »here« in the opening message I couldn't read it.

Or where is this interesting info available?

You won't find it in the 0.42 Readme, or even in the OpenCl AP Readme's because the author didn't mention it, he also used the same command line parameters that were recommended in the 0.41 OpenCL AP readme.

Claggy
ID: 1575668 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1575980 - Posted: 22 Sep 2014, 12:57:56 UTC - in response to Message 1574964.  

I (or we) don't know which app Eric will choose for reference point.

For 'Mac OS X' (32bit) just the 'non CPU instruction set' app is available.

For other OSs are also 'CPU instruction set' apps available.

Maybe the mix of all available SETI hosts (which app/s will be used) will speed up the AP CPU reference point (I guess there are not much hosts around which will crunch just with the 'non CPU instructions set' app (too old CPUs)) ... -> less Cr./AP task.

I'm correct, or wrong?


Some time ago Eric proposed to use SLOWEST app as reference point. If he will go ahead and implement this for AP subproject at least I think all will be only happy.
ID: 1575980 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1575984 - Posted: 22 Sep 2014, 13:28:57 UTC - in response to Message 1575980.  

I (or we) don't know which app Eric will choose for reference point.

For 'Mac OS X' (32bit) just the 'non CPU instruction set' app is available.

For other OSs are also 'CPU instruction set' apps available.

Maybe the mix of all available SETI hosts (which app/s will be used) will speed up the AP CPU reference point (I guess there are not much hosts around which will crunch just with the 'non CPU instructions set' app (too old CPUs)) ... -> less Cr./AP task.

I'm correct, or wrong?

Some time ago Eric proposed to use SLOWEST app as reference point. If he will go ahead and implement this for AP subproject at least I think all will be only happy.

I might be wrong, but I don't think that Eric proposed that.

I think he simply observed that the current BOINC server code operated that way, and that whatever knob Eric twiddled in an attempt to induce credit-rate parity between AP and MB, nothing changed.

Having said that, I don't think that the importance - or otherwise - of raw <rsc_fpops_est> on credit awards has been fully explored experimentally. IF the slowest app for AP v7 were the same speed as the base app here for v6 (not currently the case at Beta, so a big IF), then I'd be interested to see the outcome of halving <rsc_fpops_est> for AP here - but that may be too big and risky an experiment to carry out on the live project.
ID: 1575984 · Report as offensive
Darth Beaver Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Avatar

Send message
Joined: 20 Aug 99
Posts: 6728
Credit: 21,443,075
RAC: 3
Australia
Message 1575988 - Posted: 22 Sep 2014, 13:37:37 UTC

Umm guys please don't change or play around with credit broken . We are stuck with it and a lot of people will get rather peed off if you change it again
ID: 1575988 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1575994 - Posted: 22 Sep 2014, 13:57:24 UTC - in response to Message 1575984.  
Last modified: 22 Sep 2014, 14:20:47 UTC

I (or we) don't know which app Eric will choose for reference point.

For 'Mac OS X' (32bit) just the 'non CPU instruction set' app is available.

For other OSs are also 'CPU instruction set' apps available.

Maybe the mix of all available SETI hosts (which app/s will be used) will speed up the AP CPU reference point (I guess there are not much hosts around which will crunch just with the 'non CPU instructions set' app (too old CPUs)) ... -> less Cr./AP task.

I'm correct, or wrong?

Some time ago Eric proposed to use SLOWEST app as reference point. If he will go ahead and implement this for AP subproject at least I think all will be only happy.

I might be wrong, but I don't think that Eric proposed that.

I think he simply observed that the current BOINC server code operated that way, and that whatever knob Eric twiddled in an attempt to induce credit-rate parity between AP and MB, nothing changed.

Having said that, I don't think that the importance - or otherwise - of raw <rsc_fpops_est> on credit awards has been fully explored experimentally. IF the slowest app for AP v7 were the same speed as the base app here for v6 (not currently the case at Beta, so a big IF), then I'd be interested to see the outcome of halving <rsc_fpops_est> for AP here - but that may be too big and risky an experiment to carry out on the live project.


The 'observation' in question did happen, but had nothing to do with 'fastest' or 'slowest'. It was Eric's observation that normalising baseline, i.e. the one that receives exactly COBBLESTONE_SCALE credit, should be the 'least efficient' [does not mean slowest], and I pointed out that the 'most efficient claiming' was normalising baseline by a factor of 3.3x peak ~2x average [too efficient, by 'incorrect measurement']. That's for multibeam because of a design omission in Boinc Whetstone, since proven by SIMAP with its android app in a different scenario with opposite omission [ and similarly confusing results in a different context]. \

Numbers for AP are around 2.25x peak and ~1.5x average.

Boinc developers understand neither SIMD, nor multithreading. That's consistently demonstrated through both design and implementation.
"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.
ID: 1575994 · Report as offensive
juan BFP Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 16 Mar 07
Posts: 9786
Credit: 572,710,851
RAC: 3,799
Panama
Message 1576017 - Posted: 22 Sep 2014, 15:20:45 UTC - in response to Message 1575988.  

Umm guys please don't change or play around with credit broken . We are stuck with it and a lot of people will get rather peed off if you change it again

Hope not but did you seriusly expect that?

I´m allmost sure this time they will take some more care about credit after the MB 6->7 disaster.

If you go to the beta site, you could see the credit per WU it´s relatively similar but still a little less than the actual. The question is that will continue when it goes to main? Something similar happening in the past and what happening.... MB credit paid drops as we all knows.
ID: 1576017 · Report as offensive
Darth Beaver Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Avatar

Send message
Joined: 20 Aug 99
Posts: 6728
Credit: 21,443,075
RAC: 3
Australia
Message 1576022 - Posted: 22 Sep 2014, 15:49:59 UTC - in response to Message 1576017.  

Hope not but did you seriusly expect that?


juan BFB i don't expect anything to change . Just not shore what to expect i just noticed some of the posts talking about it so it's more a request that it not be changed . People have spent a lot of cash to build systems to get there RAC up to a certain level and will be really peed off if it is changed to much .
ID: 1576022 · Report as offensive
juan BFP Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 16 Mar 07
Posts: 9786
Credit: 572,710,851
RAC: 3,799
Panama
Message 1576026 - Posted: 22 Sep 2014, 16:03:56 UTC - in response to Message 1576022.  
Last modified: 22 Sep 2014, 16:11:00 UTC

Hope not but did you seriusly expect that?


juan BFB i don't expect anything to change . Just not shore what to expect i just noticed some of the posts talking about it so it's more a request that it not be changed . People have spent a lot of cash to build systems to get there RAC up to a certain level and will be really peed off if it is changed to much .

I totaly agree with you, maybe you not know i was one of the rise the creditscrew problem in the past? At that time i crunch MB only and my RAC drops from >400K to about 250k, so i realy knows what you talk about.

That´s exactly why i expect some more caution this time. Fingers crossed. :)
ID: 1576026 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1576203 - Posted: 22 Sep 2014, 21:09:49 UTC

Another possibility I've considered. I've never confirmed that the credits are really scaled to the least efficient CPU version for a platform. In theory, if I were to create a CPU version of SETI@home with no threading or SIMD using the Ooura FFT and release it under the plan class "calibration". After 100 results come back from that version, the credits of everything else should go up. In theory, of course.

More work would be required to allow short running calibration versions.

Then for credit calibration, all a project would need to do is generate a calibration version of every application including GPU apps and some server code to greatly limit the number of calibration apps that go out.


http://setiathome.berkeley.edu/forum_thread.php?id=73935&postid=1502273

Another possibility I've considered. I've never confirmed that the credits are really scaled to the least efficient CPU version for a platform. In theory, if I were to create a CPU version of SETI@home with no threading or SIMD using the Ooura FFT and release it under the plan class "calibration". After 100 results come back from that version, the credits of everything else should go up. In theory, of course.

More work would be required to allow short running calibration versions.

Then for credit calibration, all a project would need to do is generate a calibration version of every application including GPU apps and some server code to greatly limit the number of calibration apps that go out.


How to consider to calibrate on best valid result instead of worst one?
At least that would encourage stock optimization instead of discourage it....
ID: 1503115 · Отметить как оскорбительное
Eric KorpelaProject donorTop 5% in average credit
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar
Отправить сообщение
Присоединился: 3 Apr 99
Сообщений: 1088
Очков: 8,879,696
В среднем: 13,312
United States
Непрочитанный Сообщение 1503216 - Отправлено: 12 Apr 2014, 16:35:44 UTC - в ответ на Сообщение 1503115.
You've got it backwards. Calibrating for the best optimized version reduces the credit grants for all versions and penalizes optimizations. Calibrating for the worst increases the credit grants for all versions.


http://setiathome.berkeley.edu/forum_thread.php?id=73935&postid=1503115
http://setiathome.berkeley.edu/forum_thread.php?id=73935&postid=1503216

So if they are on CreditNew they need to keep the slowest app for 'calibration'? ;)

Yes, actually. If the speed difference is large (and if the server works as advertised) then the slow version should be sent only very rarely.

Of course the second part of that if is the hard part.

The assumption of course, is that a slow app is representative of the benchmark speeds. Of course, that's never the case. The benchmarks will always be faster than any real single threaded SISD app. That's what the old "credit multiplier" was for.

http://setiathome.berkeley.edu/forum_thread.php?id=73935&postid=1504417
ID: 1576203 · Report as offensive
Previous · 1 · 2 · 3

Message boards : Number crunching : the latest on release of AP_v7?


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