Simulations show that with the currently planned (and preliminarily implemented) S5R5 setup we would miss some signals. More tuning needed, will take at least another week.
Now that Christmas/New Year distractions are over and the people that matter are getting back to work, I presume that some action on S5R5 is probably close at hand. Also, as announced in the Windows 6.10 thread
Quote:
I just made this App "official". This gives you the opportunity now to switch back to the "official" path (you should empty your work cache before removing the app_info.xml), which I would recommend. This will allow you to get ABP1 and S5R5 work right away when we issue it.
things seem to be hotting up for a "sooner rather than later" bit of action.
It would be very good if you could provide some details on how you see the transition from S5R4 to S5R5 actually happening. Here are some specific questions:-
1. Will there be a sudden termination of S5R4 tasks - ie server will suddenly have zero S5R4 tasks to issue or will there be a transition during which both types will be available?
2. Will there be any point in completing cached work on clients? Presumably the answer to this would be "yes" if there is to be some sort of transition?
3. If somebody has a large cache would it be advantageous to reduce it now in anticipation of S5R5?
4. Will you be attempting to complete all "open" quorums by reissuing tasks when already issued ones error out or fail to return by the deadline?
Any detailed information you can share would be appreciated, thanks.
Yes, with a bit of luck (i.e. if we don't find a problem in the very last minute) we'll start S5R5 around the weekend. We were just waiting for a green light that we got last night.
Due to some remaining uncertainties we will restrict the frequency range of S5R5 to 1000Hz and then take a look at the results to decide whether we should push it up to the 1250Hz of the current S5R4. This reduces the projected total runtime of (the possibly first part of) S5R5 to about 6 months. We are working on some hoefully even more sensitive and efficient analysis methods (improving the "Hough transform"). If a new program is ready to be used by then, we'll also not extend S5R5, but start an S5R6.
The only consequence of this decision right now is that clients currently running S5R4 workunits above 1000Hz will need to get a new set of data files, while the others will just get S5R5 work for the data files they already have.
Quote:
1. Will there be a sudden termination of S5R4 tasks - ie server will suddenly have zero S5R4 tasks to issue or will there be a transition during which both types will be available?
2. Will there be any point in completing cached work on clients? Presumably the answer to this would be "yes" if there is to be some sort of transition?
3. If somebody has a large cache would it be advantageous to reduce it now in anticipation of S5R5?
4. Will you be attempting to complete all "open" quorums by reissuing tasks when already issued ones error out or fail to return by the deadline?
We'll stop the S5R4 workunit generator, but the workunits generated so far will be finished and credited. I'm not sure that pushing the last ones through is necessary, so I probably won't put time into this.
There is no (intentional) change in the crediting, so wrt the credit it shouldn't matter whether you run S5R4 or S5R5 workunits. The S5R5 ones will run a bit shorter (design goal was 50%, but I'm afraid with the adjustments we had to make afterwards we missed it by about 10%).
Perhaps it's also worth mentioning that even tho WUs will finish much faster on average, the relative runtime variation (ratio between longest and shortest runtime on the same host for different WUs) will *increase*. So it will require averaging over even more WUs than in S5R4 to really estimate the true average runtime on your systems: don't be too excited/disappointed when the first few WUs run much faster/slower than expected ;-).
It will be interesting to see how different CPU models will cope with the new run: even tho the apps are almost identical, search parameters will be different which means that the memory intensive pattern recognition part of the code (the Hough Transform already mentioned above ) will claim a larger share of overall runtime compared to the floating point arithmetic intensive "digital signal processing" part of the program. I see lots of new diagrams and benchmarking ahead :-)
the relative runtime variation ... will *increase*
More unpredictable, just what i need. I will follow the findings of the "runtime variance diagram"-guys but for now i switch.
Actually it's more predictable than ever. Thanks to the work of Bikeman the granted credit will more accurately match the runtime variation than ever before. Also too as the total Task runtime will be halved, even a 30% variation will be smaller in absolute time than before. Finally I think we got the floating point estimation better than ever and update the progress counter more frequently in the S5R5 App, so the client should be able to estimate the runtime more accurately.
Good to hear that at least the credit/hr will be more stable then, if performance can be evaluated out from credits granted then the runtime variation isnt so bad... Looking even more forward to see some S5R5 results then.
the relative runtime variation ... will *increase*
More unpredictable, just what i need. I will follow the findings of the "runtime variance diagram"-guys but for now i switch.
Actually it's more predictable than ever. Thanks to the work of Bikeman the granted credit will more accurately match the runtime variation than ever before. Also too as the total Task runtime will be halved, even a 30% variation will be smaller in absolute time than before. Finally I think we got the floating point estimation better than ever and update the progress counter more frequently in the S5R5 App, so the client should be able to estimate the runtime more accurately.
BM
Okay when are you planning on switching over? I've deleted app_info in anticipation, but it seems happy to use the 6.10 app with S5R4's still coming down at the moment.
Okay when are you planning on switching over? I've deleted app_info in anticipation, but it seems happy to use the 6.10 app with S5R4's still coming down at the moment.
good question, 40 hour work units are gettin on my nervs :| no offence, but id prefer 23:59:59 or less.
seeing without seeing is something the blind learn to do, and seeing beyond vision can be a gift.
Hi
)
Hi Bernd,
Now that Christmas/New Year distractions are over and the people that matter are getting back to work, I presume that some action on S5R5 is probably close at hand. Also, as announced in the Windows 6.10 thread
things seem to be hotting up for a "sooner rather than later" bit of action.
It would be very good if you could provide some details on how you see the transition from S5R4 to S5R5 actually happening. Here are some specific questions:-
1. Will there be a sudden termination of S5R4 tasks - ie server will suddenly have zero S5R4 tasks to issue or will there be a transition during which both types will be available?
2. Will there be any point in completing cached work on clients? Presumably the answer to this would be "yes" if there is to be some sort of transition?
3. If somebody has a large cache would it be advantageous to reduce it now in anticipation of S5R5?
4. Will you be attempting to complete all "open" quorums by reissuing tasks when already issued ones error out or fail to return by the deadline?
Any detailed information you can share would be appreciated, thanks.
Cheers,
Gary.
Hi Gary! Yes, with a bit
)
Hi Gary!
Yes, with a bit of luck (i.e. if we don't find a problem in the very last minute) we'll start S5R5 around the weekend. We were just waiting for a green light that we got last night.
Due to some remaining uncertainties we will restrict the frequency range of S5R5 to 1000Hz and then take a look at the results to decide whether we should push it up to the 1250Hz of the current S5R4. This reduces the projected total runtime of (the possibly first part of) S5R5 to about 6 months. We are working on some hoefully even more sensitive and efficient analysis methods (improving the "Hough transform"). If a new program is ready to be used by then, we'll also not extend S5R5, but start an S5R6.
The only consequence of this decision right now is that clients currently running S5R4 workunits above 1000Hz will need to get a new set of data files, while the others will just get S5R5 work for the data files they already have.
We'll stop the S5R4 workunit generator, but the workunits generated so far will be finished and credited. I'm not sure that pushing the last ones through is necessary, so I probably won't put time into this.
There is no (intentional) change in the crediting, so wrt the credit it shouldn't matter whether you run S5R4 or S5R5 workunits. The S5R5 ones will run a bit shorter (design goal was 50%, but I'm afraid with the adjustments we had to make afterwards we missed it by about 10%).
BM
BM
Perhaps it's also worth
)
Perhaps it's also worth mentioning that even tho WUs will finish much faster on average, the relative runtime variation (ratio between longest and shortest runtime on the same host for different WUs) will *increase*. So it will require averaging over even more WUs than in S5R4 to really estimate the true average runtime on your systems: don't be too excited/disappointed when the first few WUs run much faster/slower than expected ;-).
It will be interesting to see how different CPU models will cope with the new run: even tho the apps are almost identical, search parameters will be different which means that the memory intensive pattern recognition part of the code (the Hough Transform already mentioned above ) will claim a larger share of overall runtime compared to the floating point arithmetic intensive "digital signal processing" part of the program. I see lots of new diagrams and benchmarking ahead :-)
CU
Bikeman
RE: the relative runtime
)
More unpredictable, just what i need. I will follow the findings of the "runtime variance diagram"-guys but for now i switch.
Team Philippines
RE: RE: the relative
)
Actually it's more predictable than ever. Thanks to the work of Bikeman the granted credit will more accurately match the runtime variation than ever before. Also too as the total Task runtime will be halved, even a 30% variation will be smaller in absolute time than before. Finally I think we got the floating point estimation better than ever and update the progress counter more frequently in the S5R5 App, so the client should be able to estimate the runtime more accurately.
BM
BM
Good to hear that at least
)
Good to hear that at least the credit/hr will be more stable then, if performance can be evaluated out from credits granted then the runtime variation isnt so bad... Looking even more forward to see some S5R5 results then.
Team Philippines
RE: RE: RE: the
)
Okay when are you planning on switching over? I've deleted app_info in anticipation, but it seems happy to use the 6.10 app with S5R4's still coming down at the moment.
BOINC blog
RE: Okay when are you
)
good question, 40 hour work units are gettin on my nervs :| no offence, but id prefer 23:59:59 or less.
seeing without seeing is something the blind learn to do, and seeing beyond vision can be a gift.
RE: good question, 40 hour
)
If the currents S5R4 are 40h for you, S5R5 should be 20h on average.
We're running some final tests, S5R5 should start today or tomorrow if we don't find any oddities.
BM
BM
RE: RE: good question, 40
)
Great, thanks for the reply.
Mine take around 8 hours each so that means they should be around 4 hours each.
BOINC blog