Posts by Raistmer


log in
1) Message boards : Number crunching : IntelĀ® iGPU AP bench test run (e.g. @ J1900) (Message 1669672)
Posted 4 hours ago by Profile Raistmer
In view of last findings in other thread I would suggest to check parameters (unroll, ffa_block) area around your current best config under full load.
Loaded state is not negligible difference.
2) Message boards : Number crunching : Updated OpenCL AstroPulse coming main (Message 1669669)
Posted 4 hours ago by Profile Raistmer
Not while you're scratching around in http://setiathome.berkeley.edu/forum_thread.php?id=77119

Yep, versatility is required in undermanned environment.
Did you have chance to check my suggestion so far, expressed in very that thread?
http://setiathome.berkeley.edu/forum_thread.php?id=77119&postid=1664500
3) Message boards : Number crunching : Loading APU to the limit: performance considerations - ongoing research (Message 1669494)
Posted 12 hours ago by Profile Raistmer
I think no real limit, even 1 could go, but need to check (maybe "foolproof system" will not allow such values ;) )
And yes, worth to check with lower values.

What I would suggest then:
1) run on unloaded PC and find from what sizes Elapsed time stops fast decrease.
2) try values aroun or slightly less those on loaded system.
That way improved performance could be achieved. Especially if that slowdown mostly caused by memory accesses indeed (including page faults, cache misses, bus saturation and so on).
I had no opportunity to check Intel's engeeneer suggestions regarding his theory (he thinks such slowdown cause by power limitation and leads to CPU freq lowering when GPU is active, look intel forum thread for details). Maybe worth to accurately check that too.
4) Message boards : Number crunching : Updated OpenCL AstroPulse coming main (Message 1669471)
Posted 14 hours ago by Profile Raistmer
judging from this thread responses: http://setiathome.berkeley.edu/forum_thread.php?id=77052 hardly such set will be available in any foreseen future.

When app requires update because of new incompatibility or bug exposure it gets update.
5) Message boards : Number crunching : Updated OpenCL AstroPulse coming main (Message 1669439)
Posted 15 hours ago by Profile Raistmer

As well, I noticed v7 has a stock CUDA50 app now -any *better than the anon I'm running?

it's for MultiBeam. AstroPulse are OpenCL ones.
6) Message boards : Number crunching : Updated OpenCL AstroPulse coming main (Message 1669436)
Posted 15 hours ago by Profile Raistmer
Intel iGPU OpenCL AP v7.09: http://boinc2.ssl.berkeley.edu/sah/download_fanout/astropulse_7.09_windows_intelx86__opencl_intel_gpu_102.exe

Still the same .dll - http://boinc2.ssl.berkeley.edu/sah/download_fanout/libfftw3f-3-3-4_x86.dll ?

And the .cl - http://boinc2.ssl.berkeley.edu/sah/download_fanout/AstroPulse_Kernels_r****.cl ? (revision needed ;-)

Thanks.

try the same as already listed for ATi.
7) Message boards : Number crunching : Updated OpenCL AstroPulse coming main (Message 1669435)
Posted 16 hours ago by Profile Raistmer

Pre-EDIT ;-) : 'don't work?', maybe because this is always the '7.10 (opencl_nvidia_100)' app, it's just a '.xml file thing'?

yes, the same NV binary for all those plan classes
8) Message boards : Number crunching : Problem with Nvidia driver version 350.12 (Message 1669434)
Posted 16 hours ago by Profile Raistmer
Here: https://www.dropbox.com/s/1qtetgi13m61p29/AP7_win_x86_SSE2_OpenCL_NV_r2887.7z?dl=0 full archive with required files and app_info.xml example.
you did not provide CL file with kernel sources hence app crashed on CL file build stage.

Is that the same version as the updated stock files?

should be.
9) Message boards : Number crunching : Updated OpenCL AstroPulse coming main (Message 1669138)
Posted 1 day ago by Profile Raistmer
Is there a source where you can download the files and edit your current app_info.xml?

Yes, they can be downloaded manually from Berkeley's servers. Can't tell precise links though cause I'm using anonymous platform too on own hosts.
10) Message boards : Number crunching : Updated OpenCL AstroPulse coming main (Message 1669125)
Posted 1 day ago by Profile Raistmer
Maybe some already noticed that we got AstroPulse OpenCL app update for Windows and Linux.
These binaries are the best currently available ones so I would recommend those who use anonymous platform config to update to these stock ones.


You knew this question was going to be asked so I might as well ask it :).

It appears this is for ATI cards. Is there one in the works for Nvidia?


It's for all supported GPU: ATI, NV and iGPU. Look to application page more closely.
http://setiathome.berkeley.edu/apps.php

And correction for fist post: Windows and OS X for now, Linux in its way still.
11) Message boards : Number crunching : Updated OpenCL AstroPulse coming main (Message 1669096)
Posted 1 day ago by Profile Raistmer
Maybe some already noticed that we got AstroPulse OpenCL app update for Windows and Linux.
These binaries are the best currently available ones so I would recommend those who use anonymous platform config to update to these stock ones.
12) Message boards : Number crunching : Problem with Nvidia driver version 350.12 (Message 1669095)
Posted 1 day ago by Profile Raistmer
Now, when AP 7.10 released on main, one can rever to stock (if needed/wanted) and continue using new NV drivers.
13) Message boards : Number crunching : Loading APU to the limit: performance considerations - ongoing research (Message 1667734)
Posted 4 days ago by Profile Raistmer

I noticed that Haswell has Max WG size of 512 vs 256 for BayTrail. So would it make sense to test -tune to adjust WG size? Maybe -tune 64 4 1 or -tune 32 8 1.


Currently available tune options will not cover all kernel calls anyway. Some of them using default (NULL) local size so runtime free to use what it needs.
But hardly WG size would affect on difference under consideration. iGPU has wave size of 32 or 64 (not clear what actual value is) and both less than WG size. So, switching between waves will be on both devices. And global buffer size (memory that needs to be accessed) will be the same as long as -unroll and -ffa_block set to the same values for both devices.

Would be interesting to get page faults data for new config.
14) Message boards : Number crunching : Loading APU to the limit: performance considerations - ongoing research (Message 1667600)
Posted 4 days ago by Profile Raistmer
And buffer sizes and page faults? I would expect buffer sizes now match between Haswell and BayTrail. Do they?
And then would be interesting to compare number of page faults.
If they remain strongly drifferent, then they can be factor that influence performance. But if they become similar, and execution times remain same as with prev run for Haswell... then apparently the root of issue lies somewhere else.
15) Message boards : Number crunching : Problem with Nvidia driver version 350.12 (Message 1667597)
Posted 4 days ago by Profile Raistmer
Here: https://www.dropbox.com/s/1qtetgi13m61p29/AP7_win_x86_SSE2_OpenCL_NV_r2887.7z?dl=0 full archive with required files and app_info.xml example.
you did not provide CL file with kernel sources hence app crashed on CL file build stage.
16) Message boards : Number crunching : Problem with Nvidia driver version 350.12 (Message 1667220)
Posted 5 days ago by Profile Raistmer
General question @Raistmer et altera:

Would it be sufficient to just edit the "AstroPulse_Kernels_r2742.cl" and change the "bool2" to for example "bool_2" like you did for the Apple drivers and then delete the compiled "AstroPulse_Kernels_r2742.cl_GeForceGT430.bin_V7_TWIN_FFA_33788" and just let the application recompile the kernel on startup with the new driver?

Best regards, Uli


Regarding incompatibility with 350.xx NV drivers - yes. Even deletion of old binary not nessesary (cause it will be new one named differently fir 350.xx driver). Also one could try just to rename older binary to *35012 (last 5 digits are driver version).

But binaries from beta have few other improvements currently not available in main stock binaries.
17) Message boards : Number crunching : Problem with Nvidia driver version 350.12 (Message 1667173)
Posted 5 days ago by Profile Raistmer
So, thanks Claggy we already have prove that new build works correctly with 350.12: http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=18905015

I think it's safe enugh to take it to main already.
Worth to discuss with Eric server-side validation rate statistics for current beta builds and main deployment if it appropriate (not bad than for already released ones).
18) Message boards : Number crunching : Panic Mode On (97) Server Problems? (Message 1667169)
Posted 5 days ago by Profile Raistmer
BTW, Current big numbers in "ready to purge" states allows good opportunity to estimate resends overhead.
For MB we have 2.053 tasks per WU, for AP 2.45 tasks per WU.
AP validation quality needs improvements...
19) Message boards : Number crunching : Panic Mode On (97) Server Problems? (Message 1667166)
Posted 5 days ago by Profile Raistmer
It shows ~318k of tasks ready to send. Definitely work exists, but virtually impossible to get it.
If page states 318k, then those 318k were somehow counted already. Subset of "ready to send" tasks was aquired from whole DB. So, if feeder can't select some tasks from those 318k ones something definitely wrong server-side.
20) Message boards : Number crunching : Panic Mode On (97) Server Problems? (Message 1667150)
Posted 5 days ago by Profile Raistmer
Accordingly server's statistic there are plenty of tasks available:
Results ready to send 361,603 1 3m
Current result creation rate 0.2828/sec 0.0310/sec 5m

But it constantly replies no tasks:
19/04/2015 12:15:00 | SETI@home | [sched_op] Starting scheduler request
19/04/2015 12:15:00 | SETI@home | Sending scheduler request: To fetch work.
19/04/2015 12:15:00 | SETI@home | Requesting new tasks for CPU and ATI
19/04/2015 12:15:00 | SETI@home | [sched_op] CPU work request: 2391244.91 seconds; 0.00 devices
19/04/2015 12:15:00 | SETI@home | [sched_op] ATI work request: 614471.59 seconds; 0.00 devices
19/04/2015 12:15:03 | SETI@home | Scheduler request completed: got 0 new tasks
19/04/2015 12:15:03 | SETI@home | [sched_op] Server version 705
19/04/2015 12:15:03 | SETI@home | Project has no tasks available
19/04/2015 12:15:03 | SETI@home | Project requested delay of 303 seconds

Seems scripted reboot is right idea. Servers just can't work flawless too long.
P.S. And with current reliability rate local cache of only 100 tasks per device definitely hurts project performance. Such cache can't survive long enough on average modern PC to be useful in case of server issues.


Next 20

Copyright © 2015 University of California