It was really the very best project in the past, the project leaders where very active in here, telling us news regularly, the clients were good and got optimized very quick and so on.
At the moment its very different... Akos optimized the last client very good, the actual client isn't optimized in any Way. It doesn't use SSE, SSE2 or anything else, then the Windows Client is much slower than the Linux one and nobody seems to do anything against it, they just don't care.
With the new Validator they now maybe fixed some of the Validation problems..... Wow... S5R2 is done 60% and now an essential problem maybe is fixed... This could have been done much much much faster... Even if you now start to optimized something its not really worth it, when the client would be up the science run could be done 80%.....
I really was an einstein@home fan, but i dont want anymore just to waste very much CPU time just to see they don't care about the users and need month to fix big problems... Also Bruce i haven't seen for... dont know, long time...
I will look at the project and if it gets better again i will of course rejoin it, this was just an explanation on one (small) member who left the project just today...
It was really the very best project in the past, the project leaders where very active in here, telling us news regularly, the clients were good and got optimized very quick and so on.
Probably the project leaders spend less time to the users, but their activity is uncahnged. They work hard in the 'background'. I think Einstein@Home is the best project at moment too. The goal is the same, to discover the secret of the gravitation.
Quote:
At the moment its very different... Akos optimized the last client very good, the actual client isn't optimized in any Way. It doesn't use SSE, SSE2 or anything else, then the Windows Client is much slower than the Linux one and nobody seems to do anything against it, they just don't care.
The current Hierarchical Search code is nearly 10^5 times faster than the previous ( S5R1/S5RI ) code, but it is a new technique so it needs some adjustments.
Quote:
With the new Validator they now maybe fixed some of the Validation problems..... Wow... S5R2 is done 60% and now an essential problem maybe is fixed... This could have been done much much much faster...
What is the much faster way? Perhaps you are a better genius than others, but they could not solve these problems faster.
Quote:
I really was an einstein@home fan, but i dont want anymore just to waste very much CPU time just to see they don't care about the users and need month to fix big problems... Also Bruce i haven't seen for... dont know, long time...
I met Bruce on last week. I found that his enthusiasm is unbroken.
And don't forget your CPU seconds were not wasted.
Quote:
I will look at the project and if it gets better again i will of course rejoin it, this was just an explanation on one (small) member who left the project just today...
I hope you will join again and help us to discover this gravity thing... :)
I guess many people under-estimate the complexity of the mathematical methods used in Einstein@Home. The Einstein@Home client is not a piece of software exclusively build for Einstein@Home. From what I've learned about the code from exchanges with Bernd, the E@H client is a moderately thick wrapper (providing BOINC integration) around code that is used worldwide by scientists to analyze gravitational wave detector data in several projects. So changes to this code are not made easily because you want to maintain a common code basis if possible. (CPDN has a similar situation, where the client code is basically a port from a FORTRAN based full fledged meteorological modelling "production" software).
The downside is that changes in the science code may take a bit longer, but the advantage is that improvements and fixes in the code will have benefits far beyond Einstein@Home.
For example, I think it's perfectly possible that some of the improvements by Akos will "live" long enough in the shared science lib to speed up analysis of (say) data from the space-based LISA project in the next decade. From this perspective, I'm more than happy to donate CPU time even when I got 0 credits sometimes, if this helps detecting and fixing issues.
I agree, E@H is a great project! I see it this way: Take SETI@HOME: the PCs are basically "only" (more or less) filtering the data that the Arecibo observatory provides. I think Einstein@Home takes this one little step further: With this kind of gravitational wave science, it's only the *combination* of the "detectors" (LIGO / GEO / VIRGO ... ) PLUS the software that could rightfully be called an "observatory". Because it's the software that, my means of clever math, is really deciding what for (and where!) we are looking. If you want to study a certain sky region, you don't move or switch anything on the detector sites at all. Instead, you are telling the *software* where to "focus" on. So I think it's fair to say that our PCs are truly an integral part of this "virtual" GW observatory , a relatively (no pun intended :-) ) new species of astronomy instrument. So cool.
OK, I got a bit carried away by the fascination of the science, but you get the idea, right?
Agreed, and don't forget EAH is a mutli-national, multi-organization formal science project, with a pretty rigorous protocol.
This is mostly due to making sure all the participants are on the same page on all aspects of the project and they don't end up comaparing apples to oranges with the results of the science runs.
As a result, this makes things seem to move a little slower than a lot of people would like since change to project parameters have to be thoroughly vetted before being generally rolled out. In reality, these guys seem to be able to make things move pretty when compared to other major science projects. ;-)
Gary; Thanks for the kind words. I will keep in touch, but after hauling a lot of water for the project, surviving the "December to remember" with the server overload that appeared to be a very simple math calculation that escaped the project guru's, and this latest support error, I have adopted a different project.
My mistake was investing heavily in computer hardware, utility costs, and personal time to give Einstein a "full pull". With the latest handicap, I felt Einstein left me with a handful of sand for my efforts. I encourage everyone to contribute and applaud all for their efforts. I am not a "casual cruncher". My adopted project gets everything I've got. I build all of my rigs and none run at stock speed. I sweat them as high as they will go and test for stability. Einstein failed to continue providing me with a "best use" opportunity for my resources when they fielded poisoned code.
btw: Spent some time in Sydney back in '69 on leave from the little clambake in Vietnam. I will always have good things to say about the Aussies.
Gary; Thanks for the kind words. I will keep in touch, but after hauling a lot of water for the project, surviving the "December to remember" with the server overload that appeared to be a very simple math calculation that escaped the project guru's,
If I remember correctly, a major factor to this problem was a problem in the BOINC server code that resulted in excessive database locking. The bug was detected at Einstein@Home first because it used a rarely used scheduler strategy. These kind of bugs happen, in this case to the BOINC developers, that's IT.
At least that's my recollection, there may have been more than one problem involved that amplified each other.
Gary; Thanks for the kind words. I will keep in touch, but after hauling a lot of water for the project, surviving the "December to remember" with the server overload that appeared to be a very simple math calculation that escaped the project guru's,
If I remember correctly, a major factor to this problem was a problem in the BOINC server code that resulted in excessive database locking. The bug was detected at Einstein@Home first because it used a rarely used scheduler strategy. These kind of bugs happen, in this case to the BOINC developers, that's IT.
At least that's my recollection, there may have been more than one problem involved that amplified each other.
CU
BRM
Agreed, the fact that datapaks are initially issued to a limited set of hosts, some 'funkiness' in the way mySQL handled the regeneration of work for datapaks where there weren't any more eligible hosts to work the 'straggling' WU's remaining, and of course the faulty disk controller which brought the whole thing to it's knees near the end of S5R1 all contributed to that adventure.
The matter of S5R2 being a defacto Beta (and Bernd said as much right at the start in the 'S5R2', even if the announcement wasn't made on the home page) has been covered in minute detail many times. As such, it shouldn't have too surprising to anyone who even stops by casually in NC to see what's going on to figure out there would be some major turbulance involved before we would be back to the 'Timex' effect we were accustomed to on S4 and S5R1.
As it stands there is still a lot to be accomplished before S3 starts, and hopefully there is enough time left in the current run to get majority of 'showstoppers' out before then.
In my case it's been a 'stat buster' of a run, but so what? It's not like science isn't getting done, and nothing ventured, nothing gained, no discoveries, no progress. ;-)
Can you share one for a period longer than a year. Say since project inception?
I think some of these pictures/graphs (worth a thousand words) are a great tool to get new and hesitant folks to join both BOINC and any particular project.
I only check in on my "farm", 8 computer, from time to time to make sure they are still crunching and sending off the comleted wu's off in a timely manner. I never look at how small, big the wu's are or how fast the client crunches them. If E@H or any of the other distributed projects want to send alfa, beta or what ever to test, 'tis just dandy with me.
For me, i'm done with
)
For me, i'm done with Einstein for the moment.
It was really the very best project in the past, the project leaders where very active in here, telling us news regularly, the clients were good and got optimized very quick and so on.
At the moment its very different... Akos optimized the last client very good, the actual client isn't optimized in any Way. It doesn't use SSE, SSE2 or anything else, then the Windows Client is much slower than the Linux one and nobody seems to do anything against it, they just don't care.
With the new Validator they now maybe fixed some of the Validation problems..... Wow... S5R2 is done 60% and now an essential problem maybe is fixed... This could have been done much much much faster... Even if you now start to optimized something its not really worth it, when the client would be up the science run could be done 80%.....
I really was an einstein@home fan, but i dont want anymore just to waste very much CPU time just to see they don't care about the users and need month to fix big problems... Also Bruce i haven't seen for... dont know, long time...
I will look at the project and if it gets better again i will of course rejoin it, this was just an explanation on one (small) member who left the project just today...
RE: It was really the very
)
Probably the project leaders spend less time to the users, but their activity is uncahnged. They work hard in the 'background'. I think Einstein@Home is the best project at moment too. The goal is the same, to discover the secret of the gravitation.
The current Hierarchical Search code is nearly 10^5 times faster than the previous ( S5R1/S5RI ) code, but it is a new technique so it needs some adjustments.
What is the much faster way? Perhaps you are a better genius than others, but they could not solve these problems faster.
I met Bruce on last week. I found that his enthusiasm is unbroken.
And don't forget your CPU seconds were not wasted.
I hope you will join again and help us to discover this gravity thing... :)
I guess many people
)
I guess many people under-estimate the complexity of the mathematical methods used in Einstein@Home. The Einstein@Home client is not a piece of software exclusively build for Einstein@Home. From what I've learned about the code from exchanges with Bernd, the E@H client is a moderately thick wrapper (providing BOINC integration) around code that is used worldwide by scientists to analyze gravitational wave detector data in several projects. So changes to this code are not made easily because you want to maintain a common code basis if possible. (CPDN has a similar situation, where the client code is basically a port from a FORTRAN based full fledged meteorological modelling "production" software).
The downside is that changes in the science code may take a bit longer, but the advantage is that improvements and fixes in the code will have benefits far beyond Einstein@Home.
For example, I think it's perfectly possible that some of the improvements by Akos will "live" long enough in the shared science lib to speed up analysis of (say) data from the space-based LISA project in the next decade. From this perspective, I'm more than happy to donate CPU time even when I got 0 credits sometimes, if this helps detecting and fixing issues.
I agree, E@H is a great project! I see it this way: Take SETI@HOME: the PCs are basically "only" (more or less) filtering the data that the Arecibo observatory provides. I think Einstein@Home takes this one little step further: With this kind of gravitational wave science, it's only the *combination* of the "detectors" (LIGO / GEO / VIRGO ... ) PLUS the software that could rightfully be called an "observatory". Because it's the software that, my means of clever math, is really deciding what for (and where!) we are looking. If you want to study a certain sky region, you don't move or switch anything on the detector sites at all. Instead, you are telling the *software* where to "focus" on. So I think it's fair to say that our PCs are truly an integral part of this "virtual" GW observatory , a relatively (no pun intended :-) ) new species of astronomy instrument. So cool.
OK, I got a bit carried away by the fascination of the science, but you get the idea, right?
CU
BRM
Agreed, and don't forget EAH
)
Agreed, and don't forget EAH is a mutli-national, multi-organization formal science project, with a pretty rigorous protocol.
This is mostly due to making sure all the participants are on the same page on all aspects of the project and they don't end up comaparing apples to oranges with the results of the science runs.
As a result, this makes things seem to move a little slower than a lot of people would like since change to project parameters have to be thoroughly vetted before being generally rolled out. In reality, these guys seem to be able to make things move pretty when compared to other major science projects. ;-)
Alinator
Gary; Thanks for the kind
)
Gary; Thanks for the kind words. I will keep in touch, but after hauling a lot of water for the project, surviving the "December to remember" with the server overload that appeared to be a very simple math calculation that escaped the project guru's, and this latest support error, I have adopted a different project.
My mistake was investing heavily in computer hardware, utility costs, and personal time to give Einstein a "full pull". With the latest handicap, I felt Einstein left me with a handful of sand for my efforts. I encourage everyone to contribute and applaud all for their efforts. I am not a "casual cruncher". My adopted project gets everything I've got. I build all of my rigs and none run at stock speed. I sweat them as high as they will go and test for stability. Einstein failed to continue providing me with a "best use" opportunity for my resources when they fielded poisoned code.
btw: Spent some time in Sydney back in '69 on leave from the little clambake in Vietnam. I will always have good things to say about the Aussies.
Regards-tweakster
RE: Gary; Thanks for the
)
If I remember correctly, a major factor to this problem was a problem in the BOINC server code that resulted in excessive database locking. The bug was detected at Einstein@Home first because it used a rarely used scheduler strategy. These kind of bugs happen, in this case to the BOINC developers, that's IT.
At least that's my recollection, there may have been more than one problem involved that amplified each other.
CU
BRM
RE: RE: Gary; Thanks for
)
Agreed, the fact that datapaks are initially issued to a limited set of hosts, some 'funkiness' in the way mySQL handled the regeneration of work for datapaks where there weren't any more eligible hosts to work the 'straggling' WU's remaining, and of course the faulty disk controller which brought the whole thing to it's knees near the end of S5R1 all contributed to that adventure.
The matter of S5R2 being a defacto Beta (and Bernd said as much right at the start in the 'S5R2', even if the announcement wasn't made on the home page) has been covered in minute detail many times. As such, it shouldn't have too surprising to anyone who even stops by casually in NC to see what's going on to figure out there would be some major turbulance involved before we would be back to the 'Timex' effect we were accustomed to on S4 and S5R1.
As it stands there is still a lot to be accomplished before S3 starts, and hopefully there is enough time left in the current run to get majority of 'showstoppers' out before then.
In my case it's been a 'stat buster' of a run, but so what? It's not like science isn't getting done, and nothing ventured, nothing gained, no discoveries, no progress. ;-)
Alinator
[quoteI think Einstein@Home
)
[quoteI think Einstein@Home is the best project at moment too. The goal is the same, to discover the secret of the gravitation.
I only check in on my "farm",
)
I only check in on my "farm", 8 computer, from time to time to make sure they are still crunching and sending off the comleted wu's off in a timely manner. I never look at how small, big the wu's are or how fast the client crunches them. If E@H or any of the other distributed projects want to send alfa, beta or what ever to test, 'tis just dandy with me.
Jim