Seti@Home optimized science apps and information
Optimized Seti@Home apps => Discussion Forum => Topic started by: Simon on 10 Aug 2007, 06:57:12 pm
-
Hi Folks,
over at the main SETI@Home project, Multibeam apps have been released.
This marks a major turning point for the project, as we're switching from data gathered on the (now no longer operative) linefeed receiver at Arecibo to the newer ALFA Multibeam receiver (that can record 14 signals at the same time the old did one).
The updated apps also bring another change: the default credit multiplier was adjusted. It used to be 3.35, now it's 2.85. The reasoning behind this adjustment is the following - since a lot of optimized code from the lunatics apps was incorporated into the new MB stock applications, the processing speed improved significantly. Earlier, Eric Korpela wanted to increase the credit multiplier upon switching to MB; after the new code was added, the apps were so much quicker that instead it had to be reduced - to stay at approximately the same credits/hr as the old one.
This has created a bit of resentment among the power crunchers; after all, their bonus over the average user just got gutted. In contrast, all average users now process significantly more WUs, though they will continue to receive similar credit/time as before.
It all balances out in the end; at least, it should, IF:
- Most people do update their optimized apps if they use any
- There does not remain a "hard core" of crunchers refusing to update and skewing credit claims for everyone
Meaning: if you don't update your science app, you will overclaim compared to the average cruncher. Anyone care to remember what ensued the last time this happened? "Big Bada-Boom", as the fifth element would say...
So what happens if you say "ah well, screw it, it's not as if they could do anything about it"?
Well, wrong, they can and will. Namely, they (the S@H project) will reduce the credit multiplier even more to balance out the overclaimers, punishing EVERYONE for mistakes a few made. Next step will probably be, all KWSN apps up to 2.2 will be officially unwelcome at the main project.
I would ask you to consider this and make the right decision - another point to mention is that our optimization community will be much less motivated if people turn out to value credits more than fairness and scientific value. In fact, some of them would probably not continue to work on further optimizations.
So, I'd like to request that everyone update their science apps ASAP (http://lunatics.at/discussion-forum/releases-all-released-versions-are-announced-here.0.html), please (I'm uploading them as this is posted).
Regards,
Simon.
-
I addition to what Simon posted i'd like to inform you as well that the new apps (2.4) , also have an improved support for Windows Vista.
While the "older 2.2B" apps have had some issues regarding Vista compatibility and could crash on suspend/resume, resulting in ZERO credit.
However we've fixed that in our new releases and that shouldn't happen any more. If you still experience issues please report them here on the message board.
(Most probably there are going to be some additional fixes for the 32 bit Windows app. IF we notice or get notified that there are issues.)
Missing platforms ... HPUX on PARISC, IA64 and Solaris on SPARC.
Those will be release shortly (haven't had the time to compile them and of course WILL be faster that any previous released apps ;) )
So the only thing left to say.... Happy crunching using the new multibeam optimized apps.
Have fun. ;)
-
Thanks Guys. ;D
My farm is now completely running the Chicken 2.4 Apps and this is the only way to go.
Keep up the good work.
KWSN - Sir Nutsalot
-
Stats block / download counters will get updated/added tomorrow :)
Cheers,
Simon.
-
Ok here's Erics response.
(Joe is BCC'd on this, since I don't know if the email I have for him is public knowledge.)
Damn, I remember writing the code in one of the constructors in seti_header.cpp, but it's definitely not there now. That's the problem with developing on multiple machines simultaneously, sometimes a change can get lost. It looks like the 5.27 application is constant at 2.85, and we'll need to do one more release to change it.
If you want yours to do it right and not need to do a later release, the function seti_analyze() in analyzeFuncs.cpp is probably a good place to add an "if (swi.analysis_cfg.credit_rate != 0) LOAD_STORE_ADJUSTMENT=swi.analysis_cfg.credit_rate;" Like around line 189.
Whatever you do, I'll do the same.
Eric
-
It all balances out in the end
Uh-oh this post sounds a lot like "now we threaten and then we'll (they'll) punish".
But one nameless cruncher doesn't need to listen to any threatening, since we are all contributing voluntarily our CPU time, and we can voluntarily stop doing that. OTOH all the crunchers (the non-power ones, so to speak) will do more work, so the project doesn't lose anything, or better will even gain something.
So one could stop crunching and nobody will miss him/her, but he can also keep crunching and 'relatively (?) overclaim' and eventually force a credit readjustment which will affect everybody but since he/she doesn't care anymore about the project, there is no REAL deterrent to prevent him/her from doing it.
If I got this all right, in the end this is bound to happen... ::)
-
My thanks to Simon and all the Chicken app crew members.
ALL my boxes have been upgraded to 2.4 and I am so grateful to be finally crunching MB work. Been looking forward for it for a long time as we all have.
Congratulations to the Chicken crew for a job well done.
-
I just downloaded the new linux apps.
It seems a little strange to me that the app_info shows a version_num 5.21 and has not the 'structure' like the old one (every new line starts without tabs or spaces). The app itself has a 5.15 in it's name - my current one form berkeley 5.27.
I just want to make sure this is all right an I can use them...
mic.
-
It all balances out in the end
Uh-oh this post sounds a lot like "now we threaten and then we'll (they'll) punish".
Lol, no. No threat there. I'm saying exactly what I mean. Karma has a funny way of getting even, you know...
Regards,
Simon.
-
Thank you guys for your nice work again! :)
I downloaded for my Intel Core2 Extreme QX6700 the SSE3-Core2 app.
After upload and reporting from the results I have:
Version: Windows SSE3 32-bit based on seti V5.15 'Ni!'
Rev: (R-2.4|xT|FFT:IPP_SSE3|Ben-Joe)
CPUID: 'Intel C2Dx Xeon 51xx (Woodcrest)'
This is only a cosmetic-mistake?
-
Yes, that's only a cosmetic mistake.
The CPUID tables need some updating with new models.
Regards,
Simon.
-
And because of the version?
I took the SSE3-Core2 app, but in <stderr_txt> it's only SSE3.
The old app had:
Version: Windows SSE3-Core 2 32-bit based on S@H V5.15 'Noo? No - Ni!'
Revision: R-2.2B|xT|FFT:IPP_SSE3|Ben-Joe
CPUID: Intel Xeon 51xx 'Woodcrest'
Because I'm little bit nervous that I have the wrong version..
With 2.2B I had a 62.40 WU in ~3,800 seconds. (True angle range: 0.426461)
Now with 2.4, 54.16 Credits for ~5,700 seconds. (True angle range: 0.405621)
Or now the changed multiplier has SO LARGE effects?? >:( :( :'(
I'm very interested because of the 64Bit apps.
For my QX6700 it's the X64-compatible version, or?
If I buy now WinVista Home Basic 64bit, it will run with my QX6700? (support for Quad-Core?)
Now I have WinXP Home.
How much speed-up I'll have then? ;D
Thanks
-
I just downloaded the new linux apps.
It seems a little strange to me that the app_info shows a version_num 5.21 and has not the 'structure' like the old one (every new line starts without tabs or spaces). The app itself has a 5.15 in it's name - my current one form berkeley 5.27.
I just want to make sure this is all right an I can use them...
mic.
Just gave it a try. Added a 527 entry to the app_info and made it look like the old one.
...
Well, it' running...
mic.
-
I just downloaded the new linux apps.
It seems a little strange to me that the app_info shows a version_num 5.21 and has not the 'structure' like the old one (every new line starts without tabs or spaces). The app itself has a 5.15 in it's name - my current one form berkeley 5.27.
I just want to make sure this is all right an I can use them...
mic.
Just gave it a try. Added a 527 entry to the app_info and made it look like the old one.
...
Well, it' running...
mic.
...and I get credits for the results! :) :D ;D
I doubt the current app_info will do... (correct me if I'm wrong!)
Maybe someone can repack the archives with a better app_info and upload them...
mic.
-
All crunchers updated with the new app and all is well.
-
Karma has a funny way of getting even, you know...
I don't get it - what do you mean?
-
...
With 2.2B I had a 62.40 WU in ~3,800 seconds. (True angle range: 0.426461)
Now with 2.4, 54.16 Credits for ~5,700 seconds. (True angle range: 0.405621)
Or now the changed multiplier has SO LARGE effects?? >:( :( :'(
...
Yes, the difference in credits is due to the changed multiplier, and 0.426 Line feed work done with the new apps will also earn credits in the mid 50's. The difference in crunch time is because the 0.426461 is a Line feed WU, while the 0.405621 is a Multibeam WU.
Most users have noticed that Line feed WUs below 0.664 angle range have a much better credit/time ratio than those above that. The reason is that Pulse finding at 8192 FFT length isn't done above that, so the FLOP count drops abruptly, but crunch time doesn't decrease much. The 0.664 angle range is 8 times the Line feed beam width of 0.083. For Multibeam the same effect occurs at angle range 0.4 because it has a beam width of 0.05.
Sometime we'll get MB WUs with angle ranges below 0.4, there should be quite a few already in the data that's been gathered. They'll "pay" better.
Joe