Does the app run O.K when run offline in a Bench?

Claggy

The one that I did yes; I didn't manage to catch the final file from the standard app, so it stands as the comparison I did yesterday (now up there ^^ somewhere). I'd better run a few standard WUs now to be sure. Error 11 is a segfault as far as I can make out, so perhaps there's a fault in the parameters boinc is feeding to the app.

---

I'd better run a few standard WUs now to be sure.

Here are the results of running over the PG dataset.

[eesridr:seti] > for i in V7_MBtestWUs1/* ; do n=`basename $i .wu`; \
echo $i, $n; cp $i work_unit.sah;  \
time ./setiathome_x41_x86_64-pc-linux-gnu_cuda41; mkdir $n; mv result.sah $n; \
mv stderr.txt $n; done
V7_MBtestWUs1/PG0009_v7.wu, PG0009_v7

real    6m17.170s
user    0m21.482s
sys     0m1.675s
V7_MBtestWUs1/PG0395_v7.wu, PG0395_v7

real    0m34.869s
user    0m17.379s
sys     0m0.554s
V7_MBtestWUs1/PG0444_v7.wu, PG0444_v7

real    0m30.454s
user    0m16.950s
sys     0m0.399s
V7_MBtestWUs1/PG1327_v7.wu, PG1327_v7

real    0m52.212s
user    0m20.884s
sys     0m1.110s

[eesridr:seti] > ls -l PG*
PG0009_v7:
total 32
-rw-r--r-- 1 eesridr users 25022 Jun  1 21:12 result.sah
-rw-r--r-- 1 eesridr users  1300 Jun  1 21:12 stderr.txt

PG0395_v7:
total 8
-rw-r--r-- 1 eesridr users 3776 Jun  1 21:13 result.sah
-rw-r--r-- 1 eesridr users 1253 Jun  1 21:13 stderr.txt

PG0444_v7:
total 8
-rw-r--r-- 1 eesridr users 3751 Jun  1 21:13 result.sah
-rw-r--r-- 1 eesridr users 1253 Jun  1 21:13 stderr.txt

PG1327_v7:
total 12
-rw-r--r-- 1 eesridr users 5097 Jun  1 21:14 result.sah
-rw-r--r-- 1 eesridr users 1253 Jun  1 21:14 stderr.txt

You should be able to wget the tarred/zipped output from
http://www.brunel.ac.uk/~eesridr/PG.tgz

---

Wouldn't it be easier just using the KWSN Linux MB Bench v2.01.08?

Then you get a comparison of the results:

Test and Benchmark Tools

Edit: for correct link.

Claggy

Wouldn't it be easier just using the KWSN Linux MB Bench v2.01.08?

Then you get a comparison of the results:

Test and Benchmark Tools

Claggy

Possibly, if I knew about it... But I don't see anything germane on your link.

---

Wouldn't it be easier just using the KWSN Linux MB Bench v2.01.08?

Then you get a comparison of the results:

Test and Benchmark Tools

Claggy

Possibly, if I knew about it... But I don't see anything germane on your link.

Oops, posted wrong link, corrected it.

Claggy

Oops, posted wrong link, corrected it.

Claggy

Ah, that's better. :-) I'll check it out tomorrow while waiting for get_iplayer to download MotoGP...

Meanwhile the FGset have finished so I'll process them anyway.

---

Meanwhile the FGset have finished so I'll process them anyway.

[eesridr:seti] > for i in V7_WU_FGset/* ; do n=`basename $i .wu`; echo $i, $n; \
cp $i work_unit.sah;  time ./setiathome_x41_x86_64-pc-linux-gnu_cuda41; mkdir $n; \
mv result.sah $n; mv stderr.txt $n; done
V7_WU_FGset/FG00091_V7.wu, FG00091_V7

real    116m40.409s
user    1m57.721s
sys     0m27.602s
V7_WU_FGset/FG00134_V7.wu, FG00134_V7

real    5m12.050s
user    0m17.461s
sys     0m0.603s
V7_WU_FGset/FG01307_V7.wu, FG01307_V7

real    0m19.874s
user    0m16.071s
sys     0m0.199s
V7_WU_FGset/FG02968_V7.wu, FG02968_V7

real    9m10.382s
user    0m49.887s
sys     0m8.376s
V7_WU_FGset/FG03853_V7.wu, FG03853_V7

real    1m9.393s
user    0m20.379s
sys     0m1.131s
V7_WU_FGset/FG04160_V7.wu, FG04160_V7

real    0m28.049s
user    0m17.603s
sys     0m0.320s
V7_WU_FGset/FG04221_V7.wu, FG04221_V7

real    0m20.991s
user    0m16.145s
sys     0m0.210s
V7_WU_FGset/FG04317_V7.wu, FG04317_V7

real    0m18.224s
user    0m16.030s
sys     0m0.192s
V7_WU_FGset/FG04465_V7.wu, FG04465_V7

real    0m18.177s
user    0m16.001s
sys     0m0.173s
V7_WU_FGset/FG09362_V7.wu, FG09362_V7

real    0m19.182s
user    0m16.988s
sys     0m0.189s
V7_WU_FGset/FG11753_V7.wu, FG11753_V7

real    0m18.198s
user    0m16.019s
sys     0m0.174s
V7_WU_FGset/FG13462_V7.wu, FG13462_V7

real    0m18.445s
user    0m16.256s
sys     0m0.185s
V7_WU_FGset/FG24857_V7.wu, FG24857_V7

real    0m18.274s
user    0m16.083s
sys     0m0.183s
V7_WU_FGset/FG53024_V7.wu, FG53024_V7

real    0m19.254s
user    0m17.066s
sys     0m0.180s
V7_WU_FGset/FG76516_V7.wu, FG76516_V7

real    0m19.371s
user    0m17.180s
sys     0m0.188s

Results available in http://www.brunel.ac.uk/~eesridr/FG.tgz

---

Results available in http://www.brunel.ac.uk/~eesridr/FG.tgz

Having a look.... they should be taking a lot longer if I'm reading those runtimes as 20 seconds... looking into it

[Edit:] picking one example

00:00:31 (15226): Can't open init data file - running in standalone mode

I would suggest providing an init_data.xml, either from a Boinc install or the test pack. probably won't change much, only help see if there is failure further on, such as checking for Boinc's shared mem (which won't be there standalone, or in a test bench)

Restarted at 100.00 percent, with Lunatics x41zc, Cuda 4.10

Couple of things:
- That explains the 20 seconds. There must have been a completed state file present (uncleared from the first test task ?, indeed first one looks proper timing for a VLAR)
- On Windows, Cuda 4.1 release had a rather serious flaw involving the CUFFT & mixed generation GPUs in the same host. That could conceivably be a problem on Linux as well I guess, and may well explain your Sig 11's (just one possibility). Cuda 3.2, 4.2, 5, and probably the 5.5rc shouldn't have that particular issue.

---

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

I would suggest providing an init_data.xml, either from a Boinc install or the test pack. probably won't change much, only help see if there is failure further on, such as checking for Boinc's shared mem (which won't be there standalone, or in a test bench)

Copying across the init_data.xml from one of my working slots seemed to cause problems, so I deleted it.

Couple of things:
- That explains the 20 seconds. There must have been a completed state file present (uncleared from the first test task ?, indeed first one looks proper timing for a VLAR)
- On Windows, Cuda 4.1 release had a rather serious flaw involving the CUFFT & mixed generation GPUs in the same host. That could conceivably be a problem on Linux as well I guess, and may well explain your Sig 11's (just one possibility). Cuda 3.2, 4.2, 5, and probably the 5.5rc shouldn't have that particular issue.

OK; I was a bit confused about state.sah, it didn't always appear as far as I recall. I've added it to the list of files moved to the subdirectory and am re-running the test. Let's see what's happened after I've done the shopping...

---

Right, this probably makes more sense:

[eesridr:seti] > for i in V7_WU_FGset/* ; do n=`basename $i .wu`; echo $i, $n; \
cp $i work_unit.sah;  time ./setiathome_x41_x86_64-pc-linux-gnu_cuda41; mkdir $n; mv result.sah $n;
\mv stderr.txt $n; mv state.sah $n; done
V7_WU_FGset/FG00091_V7.wu, FG00091_V7

real    118m42.337s
user    1m34.298s
sys     0m20.664s
V7_WU_FGset/FG00134_V7.wu, FG00134_V7

real    112m57.705s
user    1m41.795s
sys     0m22.125s
V7_WU_FGset/FG01307_V7.wu, FG01307_V7

real    36m10.537s
user    1m28.819s
sys     0m20.910s
V7_WU_FGset/FG02968_V7.wu, FG02968_V7

real    24m35.531s
user    1m43.075s
sys     0m18.435s
V7_WU_FGset/FG03853_V7.wu, FG03853_V7

real    20m56.194s
user    1m49.579s
sys     0m25.081s
V7_WU_FGset/FG04160_V7.wu, FG04160_V7

real    19m21.320s
user    1m47.907s
sys     0m18.671s
V7_WU_FGset/FG04221_V7.wu, FG04221_V7

real    19m7.739s
user    1m45.008s
sys     0m21.347s
V7_WU_FGset/FG04317_V7.wu, FG04317_V7

real    18m43.080s
user    1m40.340s
sys     0m17.893s
V7_WU_FGset/FG04465_V7.wu, FG04465_V7

real    18m23.984s
user    1m40.191s
sys     0m16.684s
V7_WU_FGset/FG09362_V7.wu, FG09362_V7

real    13m56.876s
user    1m15.963s
sys     0m11.871s
V7_WU_FGset/FG11753_V7.wu, FG11753_V7

real    11m1.364s
user    1m11.966s
sys     0m11.003s
V7_WU_FGset/FG13462_V7.wu, FG13462_V7

real    10m57.744s
user    1m16.691s
sys     0m12.424s
V7_WU_FGset/FG24857_V7.wu, FG24857_V7

real    10m41.414s
user    1m11.185s
sys     0m10.843s
V7_WU_FGset/FG53024_V7.wu, FG53024_V7

real    10m39.754s
user    1m14.204s
sys     0m11.442s
V7_WU_FGset/FG76516_V7.wu, FG76516_V7

real    10m41.165s
user    1m10.789s
sys     0m13.692s

Results should be in the same web location -- http://www.brunel.ac.uk/~eesridr/FG.tgz. I'd run the comparison suite but I'm in the middle of watching today's motorcycle races from Mugello.

---

OK, while I don't have complete reference files for those test tasks on hand, the signal counts appear to match my earlier benches, and it appears the autocorrelations engaged without error.

Best bet at this stage might be to try live again & see if you get the weird signals error outs again, and see if the stderr online for reported tasks makes any more sense

do you use an app_info.xml something like this old x41g one ? (but obviously with updated-adapted filenames, libs and app name etc.)

<app_info>
	<app>
		<name>setiathome_enhanced</name>
	</app>
	<file_info>
		<name>setiathome_x41g_x86_64-pc-linux-gnu_cuda32</name>
		<executable/>
	</file_info>

	<file_info>
		<name>libcudart.so.3</name>
		<executable/>
	</file_info>
	<file_info>
		<name>libcufft.so.3</name>
		<executable/>
	</file_info>
	<app_version>
		<app_name>setiathome_enhanced</app_name>
		<version_num>611</version_num>
		<platform>x86_64-pc-linux-gnu</platform>
		<plan_class>cuda_fermi</plan_class>
		<avg_ncpus>0.05</avg_ncpus>
		<max_ncpus>1.0</max_ncpus>
		<coproc>
			<type>CUDA</type>
			<count>1.0</count>
		</coproc>
		<file_ref>
			<file_name>setiathome_x41g_x86_64-pc-linux-gnu_cuda32</file_name>
			<main_program/>
		</file_ref>
		<file_ref>
			<file_name>libcudart.so.3</file_name>
		</file_ref>
		<file_ref>
			<file_name>libcufft.so.3</file_name>
		</file_ref>
	</app_version>
</app_info>

---

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

Should we invite Ivan over to CA?

---

Should we invite Ivan over to CA?

yep, good Idea. Might make things a lot easier.

---

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

OK, I've started a new thread because the existing one is piggy-backing onto another thread about BOINC V7. So, here are the basics of what I did to get s@h V7 compiled on a Linux server. Note that the server has CUDA libraries and SDK installed, as well as an appropriate driver; I'm not about to go into details on how to set that up...

$ svn checkout https://setisvn.ssl.berkeley.edu/svn/branches/sah_v7_opt/Xbranch
$ cd Xbranch/
$ chmod +x _autosetup
$ ./_autosetup
$ ./configure --disable-server BOINCDIR=/home/eesridr/boinc_core_release_7_0_31/ \
--enable-sse3 CFLAGS='-O3 -march=nocona -mtune=nocona -mpreferred-stack-boundary=8 \
-fexceptions -fno-rounding-math -fno-signaling-nans -fcx-limited-range -fno-math-errno \
-ffinite-math-only -fno-trapping-math --param inline-unit-growth=3000 -DNDEBUG \
-DHAVE_STRCASECMP -fpeel-loops -funroll-loops -fgcse-sm -fgcse-las -fweb \
-I/usr/local/cuda/include'
$ make -j 8

Obviously the locations of the BOINC and CUDA include directories will need to be changed to reflect your personal set-up. Note too the remarks in the earlier thread about getting an appropriate version of BOINC to link against.

If you're interested in following the saga over the next few days, I'm experimenting on this machine.

Is nvcc required? Seems the 'configure' step is expecting it even on a system without an NVidia card. My system has an AMD/ATI card and uses xf86-video-ati as the driver, which I think means that I can't process workunits on my GPU.

---

I think you'll find it's a bit more complicated than that ...

You wont be able to process cuda on your ati - its nvidia technology

---

You wont be able to process cuda on your ati - its nvidia technology

Right, though configure appears to expect nvcc:

$ ./configure --without-cuda --without-nvcc --disable-server [...]
[...]
checking for nvcc... checking for nvcc... no
configure: error: NVCC compiler not found!

and I'm not sure of how to get past the associated error.

---

I think you'll find it's a bit more complicated than that ...

You wont be able to process cuda on your ati - its nvidia technology

Right, though configure appears to expect nvcc:

$ ./configure --without-cuda --without-nvcc --disable-server [...]
[...]
checking for nvcc... checking for nvcc... no
configure: error: NVCC compiler not found!

and I'm not sure of how to get past the associated error.

What I'd like to do is build some optimized apps that will work on my system, and perhaps the code under Xbranch is not a good place to start.

---

I think you'll find it's a bit more complicated than that ...

What I'd like to do is build some optimized apps that will work on my system, and perhaps the code under Xbranch is not a good place to start.

Hi Bobby,
You mentioned your GPU was AMD-Ati earlier, so you'd probably want to enquire about Linux-OpenCL builds for that (X-Branch, being Cuda, being proprietary nVidia only), with Lunatics. Pretty sure the source for that is somewhere around Cuda Xbranch sources. I'm not sure how far they've gotten with Linux ports of that, but imagine they're pretty close, if something isn't already operational.

I see your machine is Running V7 CPU tasks fine, but the GPU, not detected, is listed as '---'. Not sure what's up with that. You might have to check which GPUs are supported under AMD w/OpenCL, Boinc on Linux. There might also be certain drivers or runtimes needing installation for Boinc to pick it up (if it can).

HTH
Jason

---

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

What I'd like to do is build some optimized apps that will work on my system, and perhaps the code under Xbranch is not a good place to start.

Definately not the right place to start, you need the OpenCL_ATI (or the Brook flavor depending on what GPU you have), but Im not sure where can get those sources...

EDIT: Beaten by Jason...

---

Should we invite Ivan over to CA?

yep, good Idea. Might make things a lot easier.

Will see if I can get my Linux beast alive sometime after work, then figure out what's needed for the full set of Cuda apps in parallel with Ivan. If it builds *something* pretty much off the bat, that's a good start. Figuring out if it's Xbranch, boincapi, boinc or other library/driver breaking might be the adventure, we'll see.

---

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