The locality scheduling has been there (almost) all along on Einstein@Home, the implementation is more than seven years old and based on assumptions that may not all hold in what this project has evolved to by now (a major re-write has been planned for years, but continuously postponed due to more urgent things). It works still reasonably well wrt. the primary goal of keeping the download volume to a bearable minimum for the majority of participants, though. If you have different goals, you may well find its current behavior suboptimal.
We have four different searches running that have different properties (turnaround / validation times, CPU / GPU, energy efficiency, download volume / computing time etc.). If one of these doesn't suit you, why not focus on an other?
The locality scheduling has been there (almost) all along on Einstein@Home, the implementation is more than seven years old and based on assumptions that may not all hold in what this project has evolved to by now (a major re-write has been planned for years, but continuously postponed due to more urgent things). It works still reasonably well wrt. the primary goal of keeping the download volume to a bearable minimum for the majority of participants, though. If you have different goals, you may well find its current behavior suboptimal.
We have four different searches running that have different properties (turnaround / validation times, CPU / GPU, energy efficiency, download volume / computing time etc.). If one of these doesn't suit you, why not focus on an other?
BM
One question though.
If my computer has the the proper files for the work unit, why does a second computer not? Or is there, but it has not asked for a new task yet?
If my computer has the the proper files for the work unit, why does a second computer not? Or is there, but it has not asked for a new task yet?
The former is highly unlikely, the latter at least possible.
For each "fileset" (a combination of data files needed for a particular workunit) there are many workunits (the number varies, but should be of order 1000-100000), and there should be a number of clients (normally 10-100) digging through these. In your case my best guess is that the other clients of that group are too slow to keep up with yours, or dropped off that fileset group completely, e.g. by a project reset.
In the initialization phase of a "run" when no client has any of the data files yet, we set a number of "seeds" such that the clients don't get random work from all over the spectrum, but just from a limited number of such filesets. This is meant to group the clients by such filesets, precisely to minimize the likelyhood of what happened to you - that only a single computer crunches through the workunits for a given fileset, waiting almost indefinitely for a "wingman" to validate against.
Why this didn't work as designed in your particular case is something I can't tell without a close analysis that I currently don't have time for. I'll certainly get back to that when I've crunched myself through the "urgent" pile on my desk.
The locality scheduling has
)
The locality scheduling has been there (almost) all along on Einstein@Home, the implementation is more than seven years old and based on assumptions that may not all hold in what this project has evolved to by now (a major re-write has been planned for years, but continuously postponed due to more urgent things). It works still reasonably well wrt. the primary goal of keeping the download volume to a bearable minimum for the majority of participants, though. If you have different goals, you may well find its current behavior suboptimal.
We have four different searches running that have different properties (turnaround / validation times, CPU / GPU, energy efficiency, download volume / computing time etc.). If one of these doesn't suit you, why not focus on an other?
BM
BM
RE: The locality scheduling
)
One question though.
If my computer has the the proper files for the work unit, why does a second computer not? Or is there, but it has not asked for a new task yet?
RE: If my computer has the
)
The former is highly unlikely, the latter at least possible.
For each "fileset" (a combination of data files needed for a particular workunit) there are many workunits (the number varies, but should be of order 1000-100000), and there should be a number of clients (normally 10-100) digging through these. In your case my best guess is that the other clients of that group are too slow to keep up with yours, or dropped off that fileset group completely, e.g. by a project reset.
In the initialization phase of a "run" when no client has any of the data files yet, we set a number of "seeds" such that the clients don't get random work from all over the spectrum, but just from a limited number of such filesets. This is meant to group the clients by such filesets, precisely to minimize the likelyhood of what happened to you - that only a single computer crunches through the workunits for a given fileset, waiting almost indefinitely for a "wingman" to validate against.
Why this didn't work as designed in your particular case is something I can't tell without a close analysis that I currently don't have time for. I'll certainly get back to that when I've crunched myself through the "urgent" pile on my desk.
BM
BM