I've stuck with the project through the tough parts of the current run.
I'm curious - what's next? What happens when the 30 or so days left are up? Newly optimized units? Even bigger units?
I'm sure Bernd will reply in depth to your question later on, but the last I heard was that the general "battle plan" that was described here is still valid:
This means: S5R2 was a preparation run for the next (probably named S5R3) run, which will incorporate lessons learned from S5R2 and uses basically the same approach and algorithms, but over a wider range of search parameters.
It's my personal opinion/speculation that WU will not get any longer (in terms of CPU hours per WU) because S5R2 seems to mark the very upper limit of user acceptance when it comes to WU processing time (unless you use a "tickle" system of intermediate credit rewards for partially crunched WUs as in ClimatePrediction.net).
Code optimizations will eventually help to bring the processing time down, I guess.
We're still preparing this and not all decisions are final yet, but the current state is this:
- It will use the same data set as S5R1 from S5 up to Jan 2007. In principle more data gives us more sensitivity, but we decided to wait for the end of S5 so we can pre-process and analyze all of the S5 data (a full year netto!).
- It will cover a different, wider range of frequencies than S5R2 (up to about 800 Hz)
- Instead of juggling with tiny frequency ranges as we do now we will probably also split up the sky between workunits. This may give a somewhat odd movement of the direction marker in the screensaver graphics, but will gives us better control of computing overhead an the length of the workunits. It will even make the post-processing rather easier than harder.
S5R4 is already being thought on. It will probably cover the whole of S5 data, and should then (again) be the most sensitive search ever performed for gravitational waves.
It seems the cross-platform differences (observable as validation problems) are sorted out and fixed now, but apparently it takes much longer than we expected to find and fix the remaining problems in the new code. As long as these problems persist I'm afraid to introduce even more by adding more platforms and speedup measurements to the existing code, so "optimized" Apps are unlikely to come up before S5R3.
S5R4 is already being thought on. It will probably cover the whole of S5 data, and should then (again) be the most sensitive search ever performed for gravitational waves.
It seems the cross-platform differences (observable as validation problems) are sorted out and fixed now, but apparently it takes much longer than we expected to find and fix the remaining problems in the new code. As long as these problems persist I'm afraid to introduce even more by adding more platforms and speedup measurements to the existing code, so "optimized" Apps are unlikely to come up before S5R3.
BM
S5R3?! Is it typo :-) ( I mean that we are *now* R2 so the next thing .. Did You mean actually that the "optimized" Apps come after R3 but before R4 )
Given what is now happening at SETI@Home, I guess some extra effort should be taken to carefully calibrate the credits in order not to reduce the RAC for users in S5R3 :-).
Well, I don't think that will be a problem here since there are no third party opti apps to deal with, which are the ones which are taking the RAC pounding on SAH. My data is showing the rates on a given host are the generally same for the old and new stock apps, but more data needs to be collected since the rate v. angle range curve does not seem as 'flat' as it was before.
Ultimately seti's rac whores are doomed. They're dependent on the stock app's inefficiencies for their excesses and seti's under no obligation to keep from improving the official app.
For those of us not doing SETI (I'm not atm, partly because I don't have a very suitable computer at my hand since mine all have a bit little CPU cache)- what exactly happened there? People got totally imba credits?
Basically, it boils down to the project released a new application incorporating some of the optimization techniques developed for the third party apps as well as some new enhancements to go along with the raw data they now get from the ALFA receiver at Arecibo.
Since the new stock app is faster than the old stock app is, and the new opti apps have been made compliant with the rate multiplier of the new stock app (for cross project parity and to avoid claiming higher on the same SAH WU), along with quorum of 2 scoring rules has made it so if you run third party apps, your RAC took a pounding. However, when you look at the credit rate in credits per hour for a given host, the new app is about the same as the old one except for the matter I mentioned before. This part will in all likelyhood get addressed as more scoring data over a wider spectrum of angle ranges is collected.
What's next?
)
I'm sure Bernd will reply in depth to your question later on, but the last I heard was that the general "battle plan" that was described here is still valid:
This means: S5R2 was a preparation run for the next (probably named S5R3) run, which will incorporate lessons learned from S5R2 and uses basically the same approach and algorithms, but over a wider range of search parameters.
It's my personal opinion/speculation that WU will not get any longer (in terms of CPU hours per WU) because S5R2 seems to mark the very upper limit of user acceptance when it comes to WU processing time (unless you use a "tickle" system of intermediate credit rewards for partially crunched WUs as in ClimatePrediction.net).
Code optimizations will eventually help to bring the processing time down, I guess.
CU
BRM
A new run, S5R3, will follow
)
A new run, S5R3, will follow S5R2.
We're still preparing this and not all decisions are final yet, but the current state is this:
- It will use the same data set as S5R1 from S5 up to Jan 2007. In principle more data gives us more sensitivity, but we decided to wait for the end of S5 so we can pre-process and analyze all of the S5 data (a full year netto!).
- It will cover a different, wider range of frequencies than S5R2 (up to about 800 Hz)
- Instead of juggling with tiny frequency ranges as we do now we will probably also split up the sky between workunits. This may give a somewhat odd movement of the direction marker in the screensaver graphics, but will gives us better control of computing overhead an the length of the workunits. It will even make the post-processing rather easier than harder.
S5R4 is already being thought on. It will probably cover the whole of S5 data, and should then (again) be the most sensitive search ever performed for gravitational waves.
It seems the cross-platform differences (observable as validation problems) are sorted out and fixed now, but apparently it takes much longer than we expected to find and fix the remaining problems in the new code. As long as these problems persist I'm afraid to introduce even more by adding more platforms and speedup measurements to the existing code, so "optimized" Apps are unlikely to come up before S5R3.
BM
BM
RE: .... S5R4 is already
)
S5R3?! Is it typo :-) ( I mean that we are *now* R2 so the next thing .. Did You mean actually that the "optimized" Apps come after R3 but before R4 )
-- Lundi --
RE: S5R3?! Is it typo :-)
)
I doubt that they will come in the remaining days of S5R2, but will hopefully come early during S5R3.
BM
BM
Sounds really promising :-)
)
Sounds really promising :-) thanks for the update, Bernd!
Given what is now happening
)
Given what is now happening at SETI@Home, I guess some extra effort should be taken to carefully calibrate the credits in order not to reduce the RAC for users in S5R3 :-).
CU
H-BE
Well, I don't think that will
)
Well, I don't think that will be a problem here since there are no third party opti apps to deal with, which are the ones which are taking the RAC pounding on SAH. My data is showing the rates on a given host are the generally same for the old and new stock apps, but more data needs to be collected since the rate v. angle range curve does not seem as 'flat' as it was before.
Alinator
Ultimately seti's rac whores
)
Ultimately seti's rac whores are doomed. They're dependent on the stock app's inefficiencies for their excesses and seti's under no obligation to keep from improving the official app.
HA-HA!
For those of us not doing
)
For those of us not doing SETI (I'm not atm, partly because I don't have a very suitable computer at my hand since mine all have a bit little CPU cache)- what exactly happened there? People got totally imba credits?
Basically, it boils down to
)
Basically, it boils down to the project released a new application incorporating some of the optimization techniques developed for the third party apps as well as some new enhancements to go along with the raw data they now get from the ALFA receiver at Arecibo.
Since the new stock app is faster than the old stock app is, and the new opti apps have been made compliant with the rate multiplier of the new stock app (for cross project parity and to avoid claiming higher on the same SAH WU), along with quorum of 2 scoring rules has made it so if you run third party apps, your RAC took a pounding. However, when you look at the credit rate in credits per hour for a given host, the new app is about the same as the old one except for the matter I mentioned before. This part will in all likelyhood get addressed as more scoring data over a wider spectrum of angle ranges is collected.
Alinator