Linux x64 AP v5.05

[Urs Echternacht]

lordvader and others,
to find out about the reported errors i did setup and now use this host at seti beta using Ubuntu 9.04 with kernel 2.6.28 .
If the error does occur within the next 15 to 20 wus i hope i can identify the problem exactly. Otherwise i have to put a warning for Ubuntu users in the package and release to public.

There is parallel running an identical pc using openSuSE11.1 with kernel 2.6.27 which has done a few wus already without any problems.

Let's see what comes. 

[lordvader]

Well I'm currently running 2.6.27-31.

Have 2 valid units, 1  pending (inconclusive), and 4 running.
None have bailed out with error, so far so good.

Kinda surprised that your host hasn't errored yet. is it possible that the issue is a combo of 2.6.28 and amd64 cpus ?

... the output of your tasks look different to mine ... are you running the intel only version ?
(i'm not getting the "In ap_client_main.cpp: in mainloop(): at dm_chunk_large" strings)

[Urs Echternacht]

Well I'm currently running 2.6.27-31.

Have 2 valid units, 1  pending (inconclusive), and 4 running.
None have bailed out with error, so far so good.

Kinda surprised that your host hasn't errored yet. is it possible that the issue is a combo of 2.6.28 and amd64 cpus ?

... the output of your tasks look different to mine ... are you running the intel only version ?
(i'm not getting the "In ap_client_main.cpp: in mainloop(): at dm_chunk_large" strings)

That is a debug version, so if the error occurs i hope to get more exact info where. Sorry for confusing you.

  Very nice that 2.6.27 is not erroring out so far (that is what i expected). Must really be a problem with Ubuntu 9.04 and newer kernel version from 2.6.28 up. Tye's amd64 also did not throw an error, but he has done only one wu as of yet.

Correction: Tye has finished a second wu with 2.6.28 with no error and now uses a newer kernel 2.6.29.

Update: Three 32bit versions are about to enter the beta phase tomorrow. See other thread then.

Update2: Stopped using debug version, because the errors did not appear to my host.

[Matthias Lehmkuhl]

Hy Urs,
any need for additional tests for the linux 32 bit ?
 

[Matthias Lehmkuhl]

2nd post 
Matthias

[Matthias Lehmkuhl]

3rd post 
can test under ubuntu 8.10

Matthias

[Matthias Lehmkuhl]

4st post

if needed I also have a debian 32 bit system

Matthias

[Urs Echternacht]

4st post

if needed I also have a debian 32 bit system

Matthias

Thanks Matthias, but you are a little late.  Sorry, no additional tests needed. Release will come in the next days.

Only problem that showed up was with Ubuntu9.04 and derivatives and kernels 2.6.28 and up.
That was known before beta testing started. It is now clear that this is not our fault, thanks to lordvader running some extra tests.

[Matthias Lehmkuhl]

4st post

if needed I also have a debian 32 bit system

Matthias

Thanks Matthias, but you are a little late.  Sorry, no additional tests needed. Release will come in the next days.

Only problem that showed up was with Ubuntu9.04 and derivatives and kernels 2.6.28 and up.
That was known before beta testing started. It is now clear that this is not our fault, thanks to lordvader running some extra tests.

Hi Urs, thanks for the reply.
nice to hear that the tests are done.
Linux 64 bit I've activated in my 64 bit machines. 

Matthias

[Urs Echternacht]

Hi Urs, thanks for the reply.
nice to hear that the tests are done.
Linux 64 bit I've activated in my 64 bit machines. 

Matthias

Don't forget to check in a few days that you still have the most actual version.

[pp]

Aren't these new APs giving less credit? I got 1200 for the older v5 APs but only 800 for the new ones. They take 13 hours so ~60 credit per hour. Crunching VLARs gives me 50-100 credit per hour depending on the angle range (0.01-0.13). Strangely enough I crunched a few APs a week ago that gave 799 credits but only took 10 hours and that's why I tried to focus on APs instead of VLARs but I'll probably switch back to VLARs now...

[Jason G]

Aren't these new APs giving less credit? I got 1200 for the older v5 APs but only 800 for the new ones. They take 13 hours so ~60 credit per hour. Crunching VLARs gives me 50-100 credit per hour depending on the angle range (0.01-0.13). Strangely enough I crunched a few APs a week ago that gave 799 credits but only took 10 hours and that's why I tried to focus on APs instead of VLARs but I'll probably switch back to VLARs now...

Yes, erm, 'some jokers' went and made stock go faster, which raises the performance of the 'median machine', bringing the credits down.  Don't worry, further improvements to the optimised codebase are relatively esoteric, and so won't 'readily' translate to stock, though both variants are liekly to get some fundamental overhauls over time, optimised will pull gradually further ahead again.

[pp]

So you recommend I stay with AP for now or would it be more useful to the project if I crunched the VLARs again for a while?

[Jason G]

Hmm, well looking at the current Arecibo situation, it might pay to squirrel away whatever you can get  But Personally, on my machines, Astropulse seems to pay about equal per time unit to multibeam, therefore it comes down to what you prefer, versus available computation capacity.

One possible way of looking at it is that in the past AstoPulse has only been far higher paying (with optimised)  due to lacklustre performance of he stock app.  Now that it is somewhat 'cleaned up', stock is partially optimised, therefore optimised is closer to stock. 

Possibly Limited remaining work means though, that choosing one app over another turns off one of two 'taps', so limiting to one kind would see you short of work sooner then if you'd just processed both kinds.

Of course I'm trying to look at it from a productivity point of view, rather than a credit one.  If I was looking at credits I;d probably be doing Milky way or something, but for everyday use in daily life I figure that my mental picture of a spiral thing made out of dots is good enough of a model...

[pp]

The problem I have (and the rest of you too I guess) is that if I add AK_V8 to my app_info again, to be able to crunch multibeam on CPU, BOINC will also start downloading MB to CPU queue. When I then reschedule the VLARs from my CUDA-queue, BOINC goes into EDF mode and won't download neither AP nor MB to CPU. Getting APs after that is extremely difficult since BOINC seems to prefer downloading MB to CPU whenever there is deficiency. I wish there was a way to tell BOINC not to download MB specifically to CPU but still allow them to be crunched... but I guess I'll go back to AK_V8 then instead of risking running out of work. Thanks for your valuable input Jason.