There is no single source code tree (tarball or sth.). The E@H Apps are currently built from the code of four large CVS trees and a number of libs, plus some architecture-specific stuff, adding up to about 200MB or so of source code. If you really want to look through it, I can probably zip up such a build tree and send it to you. The main part of the science code is made up by LAL, the LSC Algorithm Library, available from http://www.lsc-group.phys.uwm.edu/daswg/projects/lal.html
If the source code were made available, this project would be uncommon among distributed computing projects. Most (or all) do not release source, due to potential abuse of work unit submissions. However, some potential users object to running code they do not know anything about, as they really don't know whether their cycles are really being used for what the project claims to, or whether the code really does the job of some comspiracy theorist's nightmare.
The availability of source would likely attract many contributors just for that reason. Most of the distributed computing causes are worthy, but one that encourages openness and trust of users would have an edge. Moreover, source availability would likely attract optimization enthusiasts and foster interesting disussions about ways to speed up the work. I think a lot of folks would have fun with that.
Thanks for an openminded stance on source availability, and good luck with the project. All the Best...
benson: you bring up some valid points. Seti@home released their source code along with the BOINC source when they switched to BOINC last year. The great thing about BOINC is that you can't race up your credits by returning garbage work units like you could under seti classic (not sure about other DC projects). If your result doesn't match the other 2 or 3, you don't get credit so I think it would be very difficult to cheat effectively, even with the source code. You can increase the amount of credit that is claimed for your work units but that won't do much if the project has made the validator such that it does some kind of average.
> The availability of source would likely attract many contributors just for
> that reason. Most of the distributed computing causes are worthy, but one
> that encourages openness and trust of users would have an edge. Moreover,
> source availability would likely attract optimization enthusiasts and foster
> interesting disussions about ways to speed up the work. I think a lot of
> folks would have fun with that.
who knows it might even lead to better or additional analysis of the data.
except for a security core module to ensure validity of the results, i only see advantages to making this outstanding project as open as possible.
ps are there any details of what this software actually does besides using cpu cycles :)
> There is no single source code tree (tarball or sth.). The E@H Apps are
> currently built from the code of four large CVS trees and a number of libs,
> plus some architecture-specific stuff, adding up to about 200MB or so of
> source code. If you really want to look through it, I can probably zip up such
> a build tree and send it to you. The main part of the science code is made up
> by LAL, the LSC Algorithm Library, available from
> http://www.lsc-group.phys.uwm.edu/daswg/projects/lal.html
Instead of having to send it to 30 different people's email, could you put it in a dir accessible trough a webserver? Perhaps readonly access to CVS?
The source code not only helps people understand what is going on, it also helps and inspires other projects to see how you accomplished the difficult task of making a working client. Some may learn from it.
Actually I am a bit concerned about making the whole source available without even knowing who has it.
One thing is that this may attract cheaters.
Moreover people will build and "optimize" it for their machines. At some point we got significant differencs in the outcome because of very subtle changes we made not to the code but to the build process (compilation flags etc.). We already can see the effect of overclocked CPUs in the results we get back. The algorithm or at least its implementation apparently isn't robust enough to let a large number of people play around with it without risking to render the results and thus the project useless.
If you want to know how to use BOINC or write an own BOINC application, go to Eric's Pirates site. He did a very good job writing a Boinc "hello world" and quite some Apps that are far easier to understand than ours is.
> Actually I am a bit concerned about making the whole source available without
> even knowing who has it.
>
> One thing is that this may attract cheaters.
>
> Moreover people will build and "optimize" it for their machines. At some point
> we got significant differencs in the outcome because of very subtle changes we
> made not to the code but to the build process (compilation flags etc.). We
> already can see the effect of overclocked CPUs in the results we get back. The
> algorithm or at least its implementation apparently isn't robust enough to let
> a large number of people play around with it without risking to render the
> results and thus the project useless.
>
> BM
That's pretty fascinating that overclocked CPUs can affect results. Maybe worth its own thread.
Personally I wouldn't want to run a non-mainstream binary on real work units. I'd hate to have something as mundane as that call the science into question. I'd rather give up a few percent of speed for a reliable run on the science. But I'd be willing to give some CPU time to run test code that runs on test work units. But only for code that is in serious consideration for project use, not some hobbyist/fanboy -O99 basement tweak. No doubt it would be interesting to let people try to figure out why the wierd optimizations/speeds change things, regardless.
It would be interesting to figure out a security solution to the potential abuse problem. I guess solutions might include:
- establishing statistical baselines of submissions and flagging deviations (i.e. rapid completions)
- doublechecking work units to some extent
- sampling contributors with test units (perhaps combined with the above doublecheck)
- decreasing frequency of doublechecking for reliable submitters that have a good track record.
- having the app cut a key on the user's machine to sign the work and enhance validation of submissions.
- have the app send quick checkpoints in early so ensure it's on the right track.
> Janus:
>
> If you want to know how to use BOINC or write an own BOINC application, go to
> Eric's Pirates site. He did a very good job writing a Boinc "hello world" and
> quite some Apps that are far easier to understand than ours is.
>
> BM
Thanks Bernd,
And I'll mention that the code for the graphics thread for Einstein@Home is available there too,as the "sextant" application.
source code?
)
There is no single source code tree (tarball or sth.). The E@H Apps are currently built from the code of four large CVS trees and a number of libs, plus some architecture-specific stuff, adding up to about 200MB or so of source code. If you really want to look through it, I can probably zip up such a build tree and send it to you. The main part of the science code is made up by LAL, the LSC Algorithm Library, available from http://www.lsc-group.phys.uwm.edu/daswg/projects/lal.html
BM
BM
If the source code were made
)
If the source code were made available, this project would be uncommon among distributed computing projects. Most (or all) do not release source, due to potential abuse of work unit submissions. However, some potential users object to running code they do not know anything about, as they really don't know whether their cycles are really being used for what the project claims to, or whether the code really does the job of some comspiracy theorist's nightmare.
The availability of source would likely attract many contributors just for that reason. Most of the distributed computing causes are worthy, but one that encourages openness and trust of users would have an edge. Moreover, source availability would likely attract optimization enthusiasts and foster interesting disussions about ways to speed up the work. I think a lot of folks would have fun with that.
Thanks for an openminded stance on source availability, and good luck with the project. All the Best...
bb.
Also, if I have compiled
)
Also, if I have compiled boinc myself, do I have to compile Einsten@Home. Currently I seem to be getting the following.
[Einstein@Home] Message from server: platform 'x86_64-unknown-linux-gnu' not found
---------------------------------------------------------------------------
stlforsale.com
benson: you bring up some
)
benson: you bring up some valid points. Seti@home released their source code along with the BOINC source when they switched to BOINC last year. The great thing about BOINC is that you can't race up your credits by returning garbage work units like you could under seti classic (not sure about other DC projects). If your result doesn't match the other 2 or 3, you don't get credit so I think it would be very difficult to cheat effectively, even with the source code. You can increase the amount of credit that is claimed for your work units but that won't do much if the project has made the validator such that it does some kind of average.
A member of The Knights Who Say Ni!
My BOINC stats page
> The availability of source
)
> The availability of source would likely attract many contributors just for
> that reason. Most of the distributed computing causes are worthy, but one
> that encourages openness and trust of users would have an edge. Moreover,
> source availability would likely attract optimization enthusiasts and foster
> interesting disussions about ways to speed up the work. I think a lot of
> folks would have fun with that.
who knows it might even lead to better or additional analysis of the data.
except for a security core module to ensure validity of the results, i only see advantages to making this outstanding project as open as possible.
ps are there any details of what this software actually does besides using cpu cycles :)
--
searching for gravitational waves since 2005
> There is no single source
)
> There is no single source code tree (tarball or sth.). The E@H Apps are
> currently built from the code of four large CVS trees and a number of libs,
> plus some architecture-specific stuff, adding up to about 200MB or so of
> source code. If you really want to look through it, I can probably zip up such
> a build tree and send it to you. The main part of the science code is made up
> by LAL, the LSC Algorithm Library, available from
> http://www.lsc-group.phys.uwm.edu/daswg/projects/lal.html
Instead of having to send it to 30 different people's email, could you put it in a dir accessible trough a webserver? Perhaps readonly access to CVS?
The source code not only helps people understand what is going on, it also helps and inspires other projects to see how you accomplished the difficult task of making a working client. Some may learn from it.
Actually I am a bit concerned
)
Actually I am a bit concerned about making the whole source available without even knowing who has it.
One thing is that this may attract cheaters.
Moreover people will build and "optimize" it for their machines. At some point we got significant differencs in the outcome because of very subtle changes we made not to the code but to the build process (compilation flags etc.). We already can see the effect of overclocked CPUs in the results we get back. The algorithm or at least its implementation apparently isn't robust enough to let a large number of people play around with it without risking to render the results and thus the project useless.
BM
BM
Janus: If you want to know
)
Janus:
If you want to know how to use BOINC or write an own BOINC application, go to Eric's Pirates site. He did a very good job writing a Boinc "hello world" and quite some Apps that are far easier to understand than ours is.
BM
BM
> Actually I am a bit
)
> Actually I am a bit concerned about making the whole source available without
> even knowing who has it.
>
> One thing is that this may attract cheaters.
>
> Moreover people will build and "optimize" it for their machines. At some point
> we got significant differencs in the outcome because of very subtle changes we
> made not to the code but to the build process (compilation flags etc.). We
> already can see the effect of overclocked CPUs in the results we get back. The
> algorithm or at least its implementation apparently isn't robust enough to let
> a large number of people play around with it without risking to render the
> results and thus the project useless.
>
> BM
That's pretty fascinating that overclocked CPUs can affect results. Maybe worth its own thread.
Personally I wouldn't want to run a non-mainstream binary on real work units. I'd hate to have something as mundane as that call the science into question. I'd rather give up a few percent of speed for a reliable run on the science. But I'd be willing to give some CPU time to run test code that runs on test work units. But only for code that is in serious consideration for project use, not some hobbyist/fanboy -O99 basement tweak. No doubt it would be interesting to let people try to figure out why the wierd optimizations/speeds change things, regardless.
It would be interesting to figure out a security solution to the potential abuse problem. I guess solutions might include:
- establishing statistical baselines of submissions and flagging deviations (i.e. rapid completions)
- doublechecking work units to some extent
- sampling contributors with test units (perhaps combined with the above doublecheck)
- decreasing frequency of doublechecking for reliable submitters that have a good track record.
- having the app cut a key on the user's machine to sign the work and enhance validation of submissions.
- have the app send quick checkpoints in early so ensure it's on the right track.
> Janus: > > If you want to
)
> Janus:
>
> If you want to know how to use BOINC or write an own BOINC application, go to
> Eric's Pirates site. He did a very good job writing a Boinc "hello world" and
> quite some Apps that are far easier to understand than ours is.
>
> BM
Thanks Bernd,
And I'll mention that the code for the graphics thread for Einstein@Home is available there too,as the "sextant" application.
- Eric Myers