Looks like you don't get credit for WUs until your result is confirmed as correct by another host. I still have a completed WU pending credit from February 28th because two other hosts never replied and another errored out today (if anyone bothers to look back that far for my host - yes, I know it was unstable at the time. I was very embarrassed to find out my RAM was erroring out thanks to a too-high voltage, and have prioritized Einstein@Home ever since I fixed it).
Yes, increasing pending credit when one search is coming to an end is not unusual. It's a result mostly of the locality scheduling EAH uses to minimize the bandwidth hit everyone (including the project) has to eat due to the large datapacks we chew on for EAH tasks.
So from the participants POV, the bottom line is there is no shame in having your host go insane once in a while for whatever reason and trash some work. It happens to everyone. In fact, I've even had my hosts get 'abandoned' by ATLAS from time to time when it gets busy doing something more important. Worse, when that happens it usually results in a 'No Reply' timeout, rather than a task abort or error.
As was mentioned in other threads, there really is no way for a participant to accelerate getting sent the remaining tasks for S5R6, since the scheduler is not going to send the datapacks to your host unless it has to if they are already on sufficient 'reliable' hosts to meet the progress criteria. In addition, aborting the tasks for the other searches could make them slow down. The reason is there is a fixed number of hosts working on a given set of data files (the datapack). As each host works it way through them, they eventually get assigned to new data packs, and thus there are progressively fewer hosts working on the old datapack to pick up the 'orphaned' tasks. This is the main reason you end up DL'ing a lot more datafiles at the end of the run than during beginning or mainstream phase.
So in a nutshell, experience with EAH tells me the best course of action is to just let the project send me what its got for work, and go from there.
In fact, I've even had my hosts get 'abandoned' by ATLAS from time to time when it gets busy doing something more important. Worse, when that happens it usually results in a 'No Reply' timeout, rather than a task abort or error.
Yes, I've seen that too, although there's the cc_config option. However, perhaps the ATLAS grid has not yet arrived at BOINC 6.6.10 ;-)
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
In fact, I've even had my hosts get 'abandoned' by ATLAS from time to time when it gets busy doing something more important. Worse, when that happens it usually results in a 'No Reply' timeout, rather than a task abort or error.
Yes, I've seen that too, although there's the cc_config option. However, perhaps the ATLAS grid has not yet arrived at BOINC 6.6.10 ;-)
Gruß,
Gundolf
LOL...
Yep, I guess they forgot the first rule of ACM...
You never, ever, leave your wingman (hanging)! ;-)
The degree of locality preference in Einstein work distribution means that one gets a much less diverse set of quorum partners in a given period of time on Einstein than on projects without that behavior.
So the pending trend can be pretty personal. As with the weather, the solution if you don't like it is to wait a while. It will change.
The degree of locality preference in Einstein work distribution means that one gets a much less diverse set of quorum partners in a given period of time on Einstein than on projects without that behavior.
So the pending trend can be pretty personal. As with the weather, the solution if you don't like it is to wait a while. It will change.
Yep, you pays your nickel and you takes your chances. You might get teamed up with a fleet of brand new battlecruisers which blast through them all in no time and get credit quickly. Or you might get teamed up with some old tugs (like mine), and have to wait a bit! ;-)
Of course, with them you KNOW they are going to be there every day plugging away, and they will finish and report if at all possible unless something really bad happens. :-D
The deliberate reluctance to consume bandwidth unnecessarily was a very early decision to maintain the serviceability of the project for dial-up users. That is, even those who may be on a 28K line somewhere in the world, say, will be able to participate effectively. This broadens rather than narrows the user base, as anyone can have a go at it.
Quote:
Aside : To be pure, the underlying signal processing problem actually implies us all having the entire LIGO output sitting on each home computer. From go to whoa. Just trawl up and down the parameter space ad infinitum, and see who finds the nuggets. That is ridiculously impractical of course, but all other schemes are an approximation of that ideal. One tries to virtualise the situation of numerous parallel processes acting on a commonly viewable data set.
As ever, it will depend on personal choice as to whether one is happy with the implications of that design decision. As ever, one is welcome to express that choice .....
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
Pending building
)
Looks like you don't get credit for WUs until your result is confirmed as correct by another host. I still have a completed WU pending credit from February 28th because two other hosts never replied and another errored out today (if anyone bothers to look back that far for my host - yes, I know it was unstable at the time. I was very embarrassed to find out my RAM was erroring out thanks to a too-high voltage, and have prioritized Einstein@Home ever since I fixed it).
Yes, increasing pending
)
Yes, increasing pending credit when one search is coming to an end is not unusual. It's a result mostly of the locality scheduling EAH uses to minimize the bandwidth hit everyone (including the project) has to eat due to the large datapacks we chew on for EAH tasks.
So from the participants POV, the bottom line is there is no shame in having your host go insane once in a while for whatever reason and trash some work. It happens to everyone. In fact, I've even had my hosts get 'abandoned' by ATLAS from time to time when it gets busy doing something more important. Worse, when that happens it usually results in a 'No Reply' timeout, rather than a task abort or error.
As was mentioned in other threads, there really is no way for a participant to accelerate getting sent the remaining tasks for S5R6, since the scheduler is not going to send the datapacks to your host unless it has to if they are already on sufficient 'reliable' hosts to meet the progress criteria. In addition, aborting the tasks for the other searches could make them slow down. The reason is there is a fixed number of hosts working on a given set of data files (the datapack). As each host works it way through them, they eventually get assigned to new data packs, and thus there are progressively fewer hosts working on the old datapack to pick up the 'orphaned' tasks. This is the main reason you end up DL'ing a lot more datafiles at the end of the run than during beginning or mainstream phase.
So in a nutshell, experience with EAH tells me the best course of action is to just let the project send me what its got for work, and go from there.
Alinator
RE: In fact, I've even had
)
Yes, I've seen that too, although there's the cc_config option. However, perhaps the ATLAS grid has not yet arrived at BOINC 6.6.10 ;-)
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
RE: RE: In fact, I've
)
LOL...
Yep, I guess they forgot the first rule of ACM...
You never, ever, leave your wingman (hanging)! ;-)
Alinator
RE: Any thoughts? The
)
The degree of locality preference in Einstein work distribution means that one gets a much less diverse set of quorum partners in a given period of time on Einstein than on projects without that behavior.
So the pending trend can be pretty personal. As with the weather, the solution if you don't like it is to wait a while. It will change.
RE: RE: Any thoughts?The
)
Yep, you pays your nickel and you takes your chances. You might get teamed up with a fleet of brand new battlecruisers which blast through them all in no time and get credit quickly. Or you might get teamed up with some old tugs (like mine), and have to wait a bit! ;-)
Of course, with them you KNOW they are going to be there every day plugging away, and they will finish and report if at all possible unless something really bad happens. :-D
Alinator
The deliberate reluctance to
)
The deliberate reluctance to consume bandwidth unnecessarily was a very early decision to maintain the serviceability of the project for dial-up users. That is, even those who may be on a 28K line somewhere in the world, say, will be able to participate effectively. This broadens rather than narrows the user base, as anyone can have a go at it.
As ever, it will depend on personal choice as to whether one is happy with the implications of that design decision. As ever, one is welcome to express that choice .....
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