Forum > Linux
Linux x64 AP v5.05
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:
--- Quote from: pp on 20 Sep 2009, 04:58:30 am ---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...
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version