Looks like my 'big gun' battleships are coming back to EAH sooner than I thought! ;-)
SAH has had a major meltdown of the big Sun server they use for their Master Science Database. This means until they get it fixed they are dead in the water from a work generation viewpoint, and I was only running a 1 day cache when it happened! :-(
There goes my first place ranking in my Start Date Class.
Alinator
Not to fear...everybody's in the same boat as you are (depending on cache size of course). You shouldn't lose too much ground, nobody else is getting WUs either.
A detection is going to be ultimately based upon a somewhat more than statistically significant concurrence of certain results originating from a patch of sky, see here. This will be based upon calculations from many, many machines.
For YOUR lucky machine to be processing that data ( as opposed to analysing the 'background' upon which the 'signal' will sit above ), then the odds are improving all the time. The sensitivity ( the better the hearing ), range ( the more candidates to hear ), periods of detector co-incidence ( more time correlation between 'ears' and indirectly targeting ), and noise reduction ( less rubbish to hear ) have all been steadily optimised.
But even if your box isn't the "ONE", or of the "FEW", you have been of invaluable assistance in determining the validity of the entire data pipeline process. I know I always wax lyrical - but none of this has EVER been done before, it really is cutting ( and bleeding ) edge science for which anyone at home can join in.
Actually I'd urge those who haven't already to at least have a glance at the full S3 report, you'll be able to see the terrific importance of E@H contributors to the very life of the LIGO effort. It's not simply a cost reduction technique - it couldn't be done otherwise....
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
Well, I'm not going to let you pop my bubble! I know mine will be one of them. :-D
Yep the reports are very interesting, if pretty heavy duty reading. And as you say the point of being here is to do something which has never been done, or even possible to do before. :-)
Even if that means having to live with a beta run or ten in the process! ;-)
Not to fear...everybody's in the same boat as you are (depending on cache size of course). You shouldn't lose too much ground, nobody else is getting WUs either.
LOL...
Agreed, the problem is I didn't have that much of a lead to play with.
Oh i see :-) thanks. This is really the first time I hear about this character (and also the SETI cruncher ;-) )
Mike: You were right, I just started reading the S3 science report and it is really very fascinating. Thanks for that tip!
The deadlines have to be increased during this beta testing phase or else the slow hosts are going to be wasting their time as we move up in template frequency. They do seem to get 'tougher' as it goes up.
Both my K6/300's are working perfectly, and at this point I have no reason to assume they won't complete the results they are currently running successfully.
Both of them are are on my empirically generated 'glide slope' exactly and the only problem is that they will need roughly 775 and 565 hours for the runs they are on, and are only given 336 hours to do them in. One is overdue as of a couple of hours ago already.
I don't mean to sound too critical here and I realize the app still has some problems and is as slow molasses in January at the moment, but that's not the point.
If the goal is to debug the app for the widest range of platforms capable of running EAH possible while at the same time characterize the performance of the app on those platforms, logic seems to indicate if they're running 2 to 3 times or more longer than before and the 'tightness' factor for the project is to remain the about the same, then the deadline has to be lengthened.
Yep, full ack from me for that. Dunno if I have to worry about my Coppermine, but even if not I see the logic behind your proposal.
Hi!
A possible compromise could be to stick to the current deadlines but add some logic to the server-side so that less powerful machines only get shorter WUs.
I can't remember whether this was actually done during S5R1 or at S@H, but this is possible within the BOINC framework.
RE: ARRRRGH!!!!!! Looks
)
Not to fear...everybody's in the same boat as you are (depending on cache size of course). You shouldn't lose too much ground, nobody else is getting WUs either.
Seti Classic Final Total: 11446 WU.
A detection is going to be
)
A detection is going to be ultimately based upon a somewhat more than statistically significant concurrence of certain results originating from a patch of sky, see here. This will be based upon calculations from many, many machines.
For YOUR lucky machine to be processing that data ( as opposed to analysing the 'background' upon which the 'signal' will sit above ), then the odds are improving all the time. The sensitivity ( the better the hearing ), range ( the more candidates to hear ), periods of detector co-incidence ( more time correlation between 'ears' and indirectly targeting ), and noise reduction ( less rubbish to hear ) have all been steadily optimised.
But even if your box isn't the "ONE", or of the "FEW", you have been of invaluable assistance in determining the validity of the entire data pipeline process. I know I always wax lyrical - but none of this has EVER been done before, it really is cutting ( and bleeding ) edge science for which anyone at home can join in.
Actually I'd urge those who haven't already to at least have a glance at the full S3 report, you'll be able to see the terrific importance of E@H contributors to the very life of the LIGO effort. It's not simply a cost reduction technique - it couldn't be done otherwise....
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
LOL.... Well, I'm not
)
LOL....
Well, I'm not going to let you pop my bubble! I know mine will be one of them. :-D
Yep the reports are very interesting, if pretty heavy duty reading. And as you say the point of being here is to do something which has never been done, or even possible to do before. :-)
Even if that means having to live with a beta run or ten in the process! ;-)
Alinator
RE: Not to
)
LOL...
Agreed, the problem is I didn't have that much of a lead to play with.
Alinator
@Annika RE: Sorry
)
@Annika
Ned Ludd is/was actually quite famous :D
Look here: Wikipedia
Oh i see :-) thanks. This is
)
Oh i see :-) thanks. This is really the first time I hear about this character (and also the SETI cruncher ;-) )
Mike: You were right, I just started reading the S3 science report and it is really very fascinating. Thanks for that tip!
OK, here's the sitch: The
)
OK, here's the sitch:
The deadlines have to be increased during this beta testing phase or else the slow hosts are going to be wasting their time as we move up in template frequency. They do seem to get 'tougher' as it goes up.
Both my K6/300's are working perfectly, and at this point I have no reason to assume they won't complete the results they are currently running successfully.
Both of them are are on my empirically generated 'glide slope' exactly and the only problem is that they will need roughly 775 and 565 hours for the runs they are on, and are only given 336 hours to do them in. One is overdue as of a couple of hours ago already.
I don't mean to sound too critical here and I realize the app still has some problems and is as slow molasses in January at the moment, but that's not the point.
If the goal is to debug the app for the widest range of platforms capable of running EAH possible while at the same time characterize the performance of the app on those platforms, logic seems to indicate if they're running 2 to 3 times or more longer than before and the 'tightness' factor for the project is to remain the about the same, then the deadline has to be lengthened.
Alinator
Yep, full ack from me for
)
Yep, full ack from me for that. Dunno if I have to worry about my Coppermine, but even if not I see the logic behind your proposal.
RE: Yep, full ack from me
)
Hi!
A possible compromise could be to stick to the current deadlines but add some logic to the server-side so that less powerful machines only get shorter WUs.
I can't remember whether this was actually done during S5R1 or at S@H, but this is possible within the BOINC framework.
CU
BRM
It was done for S5R1 but not
)
It was done for S5R1 but not for S5RI iirc.