This minor problem of an optimized application on the other hand was started by Akos and ended by Akos. Everyone wants to see word of the project developers on this, yet they never saw it when Akos started it. So why question Akos when he wants it ended?
So true. Especially since Akos has been (and may still be) paid by E@H as a contractor. He has written code for them, he is talking to the developers on a regular basis. He is listened to (why do we have optimized apps in S5?). So if they told him to stop, and he made the request for all of us to stop, his word should not be questioned. His word is as good as Bruce's, Bernard's, etc. in my eyes.
Pooh Bear,
Again, the point has been missed. Akos' request to stop using his apps should be complied with. I do not question his word on or authority on that issue. I would just like to know more than we know now. We know it has something to do with "being official" but not much else. Akos' apps and the process we used to implement them were fine for S4; but, all of a sudden, they are not OK for S5. I am sure there are good reasons for the change. And I think we deserve to know what they are. I don't think Akos is the one to do that. I think it's Bruce's job. I hope he sees fit to tell us.
Thank you for your last couple of well-said posts. However, I believe that you (in very much the same manner as the creators of BOINC did and continue to do) have missed the 'third leg' of the science of DC projects. The first two legs seem clear: the substantive research of the specific project (gravitational waves here) and the general computer science that makes DC function (here the BOINC system, though other systems of course exist). What is missing is the third leg: the social science of DC. Interstingly, some of the points and examples in your posts are exactly unexplored questions that need social science research to understand how DC functions (and how it might function more efficiently). For example, it would seem to be very valuable information to know what motivates people to participate in DC (and I am sure that there are numerous reasons including some that would lead some volunteers to jump into your no-purpose credit-only example project). Likewise, it might be valuable to know who would spoof the project with their own hidden optimized routine and to understand what is actually in it for them.
That is so true. I think you could spend a career ( or three ) on that! Actually I vaguely recall suggesting that myself sometime ... :-)
Quote:
I guess my point here is fairly simple. Projects are clearly moving to enhance their understanding of substantive science (e.g., moving from S4 to the more detailed analysis of S5) and are clearly interested in doing DC more efficiently via better computer science (e.g., the incorporation of optimizations into the S5 analysis). Why do all the projects continue to ignore the possibility of increased efficiency through the social science of DC(with some exception to Rosetta, though their efforts are not scientific). For example, one could increase the throughput here at EAH by optimizing the client to be twice as fast or one could understand the who, where, and why of project participants and posibly gain the same increase by doubling the participant pool or increasing the number of large farm crunchers to effectively double the number of crunching hosts.
To the best of my knowledge the limits of efficiency, for the science apps, are pretty close to optimal ( within a few percent ). There are no order of magnitude improvements to be gained, Akos ( all hail!! ) has brought us thus far. For S5, and this is a crucial point of understanding, the LIGO's are operating at their design specification - which implies searching for a signal at the level of 10 to the power of minus 18 roughly.
[ignore this bit if you like]
The analysis is done by 'multiplying' a signal template ( a smart guess at a signal pattern type ) by the actual recieved signal and 'integrating' over time. ( I have horribly simplified here. ) Any noise will grow as square root of integration time, whereas a 'real' signal will grow linearly with said time. This is how one filters for the needle in the haystack. One would also like any candidate detection to be highly probable ( statistics are involved ) rather than complete happenstance that produces a wiggle of just the right shape. This could be say a log truck passing by 20 miles away, combined with wind humming in the trees down the access road, a closer sneeze, and a few extra excitable photons on a mirror - all conspiring perfectly to fool us.
[/ignore this bit if you like]
My basic point is that the science aim brings irreducible requirements to the algorithm and it's implementation. For sure compiler choices, snappy optimisations, hand coding etc can trim a bit but I think we are close enough.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Again, the point has been missed. Akos' request to stop using his apps should be complied with. I do not question his word on or authority on that issue. I would just like to know more than we know now. We know it has something to do with "being official" but not much else. Akos' apps and the process we used to implement them were fine for S4; but, all of a sudden, they are not OK for S5. I am sure there are good reasons for the change. And I think we deserve to know what they are. I don't think Akos is the one to do that. I think it's Bruce's job. I hope he sees fit to tell us.
Stick
He did tell us why, the scientist have not tested the applications, and they are not going to accept the information. Now is testing being done to accept them we have not been told. It also was stated it was causing some database problems.
Those are very valid reasons. If the database is choking on the information after it's been validated, and then sent onto the next phase, I can see why we were asked to stop. I hope that more testing can be done, and that we might be able to move to a faster application in the future, but allow the programmers their time.
There are those out there that won't stop using the optimizations though, even though it's been asked of them, by the person who wrote them, and explained that it is causing issues. This is what frustrates me. He is in official enough capacity to tell us there are issues.
I do not see why Bruce, et al have to be involved. They never said anything about the S4 optimizations, officially, until they started paying Akos, and invited him to see one of the facilities, and to see the real programming behind the scenes. He puts a lot of input into the official application of S5. He tried being nice and making some adjustments to the current application, but he was officially told it was causing database issues, etc. So, the word was official, it's just that he told us. What makes people think that they will officially say anything this time? What's so hard to believe about that?
What makes people think that they will officially say anything this time? What's so hard to believe about that?
Stick has a good point, we deserve an explanation direct from the source. BOINC applications do not seem to realize what a valuable resource is available in optimized applications. They need to have a better procedure for allowing for the testing of these applications. Does anyone really believe that Akos has not made amazing contributions to this application and several others? I am sure that application personnel are overworked, but keeping us crunchers informed should be a high priority. The idea that we are just peons, and the applications folks are our honchos is self destructive to the whole idea of BOINC.
Stick has a good point, we deserve an explanation direct from the source. BOINC applications do not seem to realize what a valuable resource is available in optimized applications. They need to have a better procedure for allowing for the testing of these applications. Does anyone really believe that Akos has not made amazing contributions to this application and several others? I am sure that application personnel are overworked, but keeping us crunchers informed should be a high priority. The idea that we are just peons, and the applications folks are our honchos is self destructive to the whole idea of BOINC.
Considering that the developers paid Akos for his input, I'd tend to think they already know that he's made amazing contributions. As much as people may want to think it, they're not idiots.
If anyone has experience with academic research, funding, proposals, QA, etc., they'd understand how immensely difficult it can be at times to forge ahead and say what needs to be said. I've had times in my research where a certain thing needs to be said or be done, but you have to hold your tongue and hands and wait until the moment is right, for whatever reason it may be.
Well, i'm off to Rosetta 'til things settle down here again...
You get exactly the credits granted, you're claiming... ;)
In case anyone is interested: http://boinc.bakerlab.org/rosetta/
See you over there... :D
Well, i'm off to Rosetta 'til things settle down here again...
You get exactly the credits granted, you're claiming... ;)
That's certainly been my experience with the S5 WUs so far. Previously my Macs would get anything between 35% and 250% of what they claimed, according to the 'luck of the draw' in the quorum, but now they're perfectly consistent.
That's certainly been my experience with the S5 WUs so far. Previously my Macs would get anything between 35% and 250% of what they claimed, according to the 'luck of the draw' in the quorum, but now they're perfectly consistent.
Well, but you and the fools minusing my post don't get it, that here the credit is pre-granted by the server and you get, what the server decided. Rosetta uses the credit claimed by the client based on the benchmark to grant the credit. If you don't know or understand the difference, then never mind... ;)
RE: RE: This minor
)
Pooh Bear,
Again, the point has been missed. Akos' request to stop using his apps should be complied with. I do not question his word on or authority on that issue. I would just like to know more than we know now. We know it has something to do with "being official" but not much else. Akos' apps and the process we used to implement them were fine for S4; but, all of a sudden, they are not OK for S5. I am sure there are good reasons for the change. And I think we deserve to know what they are. I don't think Akos is the one to do that. I think it's Bruce's job. I hope he sees fit to tell us.
Stick
RE: @Mike Hewson Thank
)
That is so true. I think you could spend a career ( or three ) on that! Actually I vaguely recall suggesting that myself sometime ... :-)
To the best of my knowledge the limits of efficiency, for the science apps, are pretty close to optimal ( within a few percent ). There are no order of magnitude improvements to be gained, Akos ( all hail!! ) has brought us thus far. For S5, and this is a crucial point of understanding, the LIGO's are operating at their design specification - which implies searching for a signal at the level of 10 to the power of minus 18 roughly.
[ignore this bit if you like]
The analysis is done by 'multiplying' a signal template ( a smart guess at a signal pattern type ) by the actual recieved signal and 'integrating' over time. ( I have horribly simplified here. ) Any noise will grow as square root of integration time, whereas a 'real' signal will grow linearly with said time. This is how one filters for the needle in the haystack. One would also like any candidate detection to be highly probable ( statistics are involved ) rather than complete happenstance that produces a wiggle of just the right shape. This could be say a log truck passing by 20 miles away, combined with wind humming in the trees down the access road, a closer sneeze, and a few extra excitable photons on a mirror - all conspiring perfectly to fool us.
[/ignore this bit if you like]
My basic point is that the science aim brings irreducible requirements to the algorithm and it's implementation. For sure compiler choices, snappy optimisations, hand coding etc can trim a bit but I think we are close enough.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Pooh Bear, Again, the
)
He did tell us why, the scientist have not tested the applications, and they are not going to accept the information. Now is testing being done to accept them we have not been told. It also was stated it was causing some database problems.
Those are very valid reasons. If the database is choking on the information after it's been validated, and then sent onto the next phase, I can see why we were asked to stop. I hope that more testing can be done, and that we might be able to move to a faster application in the future, but allow the programmers their time.
There are those out there that won't stop using the optimizations though, even though it's been asked of them, by the person who wrote them, and explained that it is causing issues. This is what frustrates me. He is in official enough capacity to tell us there are issues.
I do not see why Bruce, et al have to be involved. They never said anything about the S4 optimizations, officially, until they started paying Akos, and invited him to see one of the facilities, and to see the real programming behind the scenes. He puts a lot of input into the official application of S5. He tried being nice and making some adjustments to the current application, but he was officially told it was causing database issues, etc. So, the word was official, it's just that he told us. What makes people think that they will officially say anything this time? What's so hard to believe about that?
RE: Pooh Bear, What makes
)
Stick has a good point, we deserve an explanation direct from the source. BOINC applications do not seem to realize what a valuable resource is available in optimized applications. They need to have a better procedure for allowing for the testing of these applications. Does anyone really believe that Akos has not made amazing contributions to this application and several others? I am sure that application personnel are overworked, but keeping us crunchers informed should be a high priority. The idea that we are just peons, and the applications folks are our honchos is self destructive to the whole idea of BOINC.
RE: Stick has a good
)
Considering that the developers paid Akos for his input, I'd tend to think they already know that he's made amazing contributions. As much as people may want to think it, they're not idiots.
If anyone has experience with academic research, funding, proposals, QA, etc., they'd understand how immensely difficult it can be at times to forge ahead and say what needs to be said. I've had times in my research where a certain thing needs to be said or be done, but you have to hold your tongue and hands and wait until the moment is right, for whatever reason it may be.
Well, i'm off to Rosetta 'til
)
Well, i'm off to Rosetta 'til things settle down here again...
You get exactly the credits granted, you're claiming... ;)
In case anyone is interested: http://boinc.bakerlab.org/rosetta/
See you over there... :D
Aloha, Uli
RE: Actually I vaguely
)
Found it here.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Well, i'm off to
)
That's certainly been my experience with the S5 WUs so far. Previously my Macs would get anything between 35% and 250% of what they claimed, according to the 'luck of the draw' in the quorum, but now they're perfectly consistent.
here is a interesting
)
here is a interesting discussion about optimization
britta
RE: That's certainly been
)
Well, but you and the fools minusing my post don't get it, that here the credit is pre-granted by the server and you get, what the server decided. Rosetta uses the credit claimed by the client based on the benchmark to grant the credit. If you don't know or understand the difference, then never mind... ;)
Aloha, Uli