Is this the same bug that was first found when it was discovered to be behind Einstein crashes?
Yes, an Einstein@Home user made the bug report and helped pinpoint the change in the kernel sources that introduced the bug.
CU
HB
Due to lack of time, I currently didn't have time to find if this bug is known, read how I can report kernel bug and do the necessary testing (I don't use vanilla kernel now). I plan to devote to this later. Is this reocurrence already reported?
With S5GCE over 90% done, I was wondering what would be next. Is there is enough S6 data to start crunching that?
Thanks for reminding me of an update. There is quite some work in progress and discussion going on right now as we prepare the next run called "S5GC1".
We'll use the same data that we did for S5GCE - the best 25h stretches from both years of S5. We'll have applications that run about 3x as fast as the current ones, there's a bit room left for further speed improvements. We'll use the same FStat code that we've been using more or less unchanged since S5R1; the new "resampling FStat" code isn't ready to be used yet. S5GC1 will be designed for a total runtime of 6 months.
We're currently discussing measurements to not stress our download servers (and the client wires) by the application speedup. One thing that would be astrophysical interesting and easy to implement is to increase the spindown range we search for in every workunit by about the factor of the application speedup. This would mean that although a GC1 task does three times the computation of a GCE one, its runtime and therefore the total computing time per download volume ratio will stay about the same. We're also discussing then to cut the resulting workunits in halve, they are a bit on the longer end now.
We'll use the same FStat code that we've been using more or less unchanged since S5R1; the new "resampling FStat" code isn't ready to be used yet.
Are there plans to deploy the new FStat code midway through S5GC1, or will it result in differences large enough to require waiting until the next run?
Are there plans to deploy the new FStat code midway through S5GC1, or will it result in differences large enough to require waiting until the next run?
There are no solid plans to do so. We may test applications with that code during S5GC1, but to unveil the codes full speedup potential one needs to set up the workunits differently and possibly generate new data files, too, which would mean a new run. However if things go surprisingly well we may start the next run well before S5GC1 ends.
Are there plans to deploy the new FStat code midway through S5GC1, or will it result in differences large enough to require waiting until the next run?
There are no solid plans to do so. We may test applications with that code during S5GC1, but to unveil the codes full speedup potential one needs to set up the workunits differently and possibly generate new data files, too, which would mean a new run. However if things go surprisingly well we may start the next run well before S5GC1 ends.
BM
Does this mean that new workunits will bring us the same amount of credits as the current S5GCE WUs do?
I have a solution for "Global Correlations S5 Search #1 1.02 (SSE2) for linux Ubuntu v10.4
Apparently this type of task do not support computer shutdown
For the users running several projects, it seems it's the same problem when BOINC stops E@H tasks for running another.
The solution for the crunchers seems be:
-running only E@H tasks
-never stop your computer
For the others, you can not allow this type of task on E@H preferences and run only "Binary Pulsar Search of Arecibo". It's not my decision.
It was my contribution for E@H project coming from an amateur.
Sorry for my english
I have a solution for "Global Correlations S5 Search #1 1.02 (SSE2) for linux Ubuntu v10.4
Apparently this type of task do not support computer shutdown
For the users running several projects, it seems it's the same problem when BOINC stops E@H tasks for running another.
The solution for the crunchers seems be:
-running only E@H tasks
-never stop your computer
For the others, you can not allow this type of task on E@H preferences and run only "Binary Pulsar Search of Arecibo". It's not my decision.
It was my contribution for E@H project coming from an amateur.
Sorry for my english
This explains what happens to me. I am running SuSE 11.1 Linux and 6 BOINC projects on it, plus a virtual machine running SETI@home on Solaris via VirtualBox. All there projects proceed regularly. Only the latest Einstein@home unit does not proceed at all and seems to run in a loop. See my posts in Cruncher's Corner, Got first file of S5GC1.
Tullio
RE: RE: Thanks for help.
)
Yes, an Einstein@Home user made the bug report and helped pinpoint the change in the kernel sources that introduced the bug.
CU
HB
RE: RE: RE: Thanks for
)
Due to lack of time, I currently didn't have time to find if this bug is known, read how I can report kernel bug and do the necessary testing (I don't use vanilla kernel now). I plan to devote to this later. Is this reocurrence already reported?
Martin
With S5GCE over 90% done, I
)
With S5GCE over 90% done, I was wondering what would be next. Is there is enough S6 data to start crunching that?
RE: With S5GCE over 90%
)
Thanks for reminding me of an update. There is quite some work in progress and discussion going on right now as we prepare the next run called "S5GC1".
We'll use the same data that we did for S5GCE - the best 25h stretches from both years of S5. We'll have applications that run about 3x as fast as the current ones, there's a bit room left for further speed improvements. We'll use the same FStat code that we've been using more or less unchanged since S5R1; the new "resampling FStat" code isn't ready to be used yet. S5GC1 will be designed for a total runtime of 6 months.
We're currently discussing measurements to not stress our download servers (and the client wires) by the application speedup. One thing that would be astrophysical interesting and easy to implement is to increase the spindown range we search for in every workunit by about the factor of the application speedup. This would mean that although a GC1 task does three times the computation of a GCE one, its runtime and therefore the total computing time per download volume ratio will stay about the same. We're also discussing then to cut the resulting workunits in halve, they are a bit on the longer end now.
BM
BM
RE: We'll use the same
)
Are there plans to deploy the new FStat code midway through S5GC1, or will it result in differences large enough to require waiting until the next run?
RE: Are there plans to
)
There are no solid plans to do so. We may test applications with that code during S5GC1, but to unveil the codes full speedup potential one needs to set up the workunits differently and possibly generate new data files, too, which would mean a new run. However if things go surprisingly well we may start the next run well before S5GC1 ends.
BM
BM
RE: RE: Are there plans
)
Does this mean that new workunits will bring us the same amount of credits as the current S5GCE WUs do?
The status page needs updated
)
The status page needs updated to add S5GCE to the old searches list and add S5GC1.
I have a solution for "Global
)
I have a solution for "Global Correlations S5 Search #1 1.02 (SSE2) for linux Ubuntu v10.4
Apparently this type of task do not support computer shutdown
For the users running several projects, it seems it's the same problem when BOINC stops E@H tasks for running another.
The solution for the crunchers seems be:
-running only E@H tasks
-never stop your computer
For the others, you can not allow this type of task on E@H preferences and run only "Binary Pulsar Search of Arecibo". It's not my decision.
It was my contribution for E@H project coming from an amateur.
Sorry for my english
just a poet
RE: I have a solution for
)
This explains what happens to me. I am running SuSE 11.1 Linux and 6 BOINC projects on it, plus a virtual machine running SETI@home on Solaris via VirtualBox. All there projects proceed regularly. Only the latest Einstein@home unit does not proceed at all and seems to run in a loop. See my posts in Cruncher's Corner, Got first file of S5GC1.
Tullio