Can you tell us anything about it yet: S5R7 or S6R1? Similar to the current run, or significant differences?
The data taken in S6 so far is actually noisier than what we have of S5, so we'll stick to S5 data for now.
We're working on a new program that will combine a new, faster implementation of the FStat calculation with a new method called 'Global Correlation Transform' that will supersede the 'Hough Transform' used in the current HierarchicalSearch, resulting in the most sensitive search for continuous signals that we know, and still requiring much less computing power for the same parameter space.
We work on turning the program into a reliable BOINC application and on setting up a search design (i.e. how to split up the parameter space into workunits), which will result in a new workunit generator and possibly new data files.
With luck, we'll have that ready by the time we run out of S5R6 work. If we aren't, we'll insert a short run with the same application and data as we used on S5R5 and S5R6, but looking into higher frequencies. S5R5 went up to 1kHz, S5R6 covered 1kHz to 1.2kHz, the current data files allow to search up to 1.5kHz.
BM
For those curious in the new 'Global Correlation Transform' run, this(.pdf) bit of light reading should clear things up.
For those curious in the new 'Global Correlation Transform' run, this(.pdf) bit of light reading should clear things up.
Which poor developer found this on their desk??
Speaking as a developer (not on E@H) there are far worse things than to be given an overly technical spec written by people who know exactly what they want. As usual Dilbert captures the normal requirement acquisition problem perfectly.
For anyone who doesn't want to read through the entire paper, or try and figure out what it means: figure 2 sums up what it means in terms of the likelihood of making a detection. The signal strength that's almost certain to be detected with the new approach is an order of magnitude fainter than with the old one: 1 part in 10^-23 vs 1 part in 10^-22. The point at which the detection probability approaches zero remains roughly fixed at 1 part in 2 * 10^-24. The improvement comes primarily by reducing the width of the zone where a signal might be detected or might not be.
We stumbled over a major problem with our new Windows S5GCE App. Looks like that we'll run out of S5R6 work before we can start S5GCE, i.e. for some days we will send out only ABP work.
Originally we planned to generate just a few S5GCE tasks and then wait until they were reported back.
However the project behaved quite sluggish after we ran out of S5R6 work, so we decided to issue S5GCE work right away to keep the client busy and stop them from hammering on the server.
The Application had been tested as far as we could on the test project, but not yet 'in the wild' where it could behave quite differently.
Originally we planned to generate just a few S5GCE tasks and then wait until they were reported back.
However the project behaved quite sluggish after we ran out of S5R6 work, so we decided to issue S5GCE work right away to keep the client busy and stop them from hammering on the server.
The Application had been tested as far as we could on the test project, but not yet 'in the wild' where it could behave quite differently.
BM
Hmmm...
Interesting. In any event I've picked up a few, including one on one of my AMD old timers (251595}.
So far so good there. After one and a half hours of run time I'm projecting about a 300 Ksec execution time (which is decreasing at this point).
I'm having a lot of trouble actually getting these tasks at the moment. Very rarely, one of the required files will begin downloading - at which point it finishes quickly - but most of the time they just sit there until BOINC decides to try the next file in the list. Is this simply a result of server-wide performance issues, or an actual problem with new code?
I'm having a lot of trouble actually getting these tasks at the moment. Very rarely, one of the required files will begin downloading - at which point it finishes quickly - but most of the time they just sit there until BOINC decides to try the next file in the list. Is this simply a result of server-wide performance issues, or an actual problem with new code?
Same here.
According to server status, only one out of five mirrors are up.
I'm having a lot of trouble actually getting these tasks at the moment. Very rarely, one of the required files will begin downloading - at which point it finishes quickly - but most of the time they just sit there until BOINC decides to try the next file in the list. Is this simply a result of server-wide performance issues, or an actual problem with new code?
This seems to be a common problem on our download mirrors, neither with the apps nor the main server.
I'm having a lot of trouble actually getting these tasks at the moment. Very rarely, one of the required files will begin downloading - at which point it finishes quickly - but most of the time they just sit there until BOINC decides to try the next file in the list. Is this simply a result of server-wide performance issues, or an actual problem with new code?
This seems to be a common problem on our download mirrors, neither with the apps nor the main server.
BM
LOL...
I'd say so! If the status page is correct we can only draw from AEI-Hannover right now.
And there's no telling how long it can hold up under the onslaught! ;-)
RE: RE: Can you tell us
)
For those curious in the new 'Global Correlation Transform' run, this(.pdf) bit of light reading should clear things up.
Which poor developer found this on their desk??
RE: For those curious in
)
Speaking as a developer (not on E@H) there are far worse things than to be given an overly technical spec written by people who know exactly what they want. As usual Dilbert captures the normal requirement acquisition problem perfectly.
For anyone who doesn't want to read through the entire paper, or try and figure out what it means: figure 2 sums up what it means in terms of the likelihood of making a detection. The signal strength that's almost certain to be detected with the new approach is an order of magnitude fainter than with the old one: 1 part in 10^-23 vs 1 part in 10^-22. The point at which the detection probability approaches zero remains roughly fixed at 1 part in 2 * 10^-24. The improvement comes primarily by reducing the width of the zone where a signal might be detected or might not be.
We stumbled over a major
)
We stumbled over a major problem with our new Windows S5GCE App. Looks like that we'll run out of S5R6 work before we can start S5GCE, i.e. for some days we will send out only ABP work.
BM
BM
Originally we planned to
)
Originally we planned to generate just a few S5GCE tasks and then wait until they were reported back.
However the project behaved quite sluggish after we ran out of S5R6 work, so we decided to issue S5GCE work right away to keep the client busy and stop them from hammering on the server.
The Application had been tested as far as we could on the test project, but not yet 'in the wild' where it could behave quite differently.
BM
BM
RE: Originally we planned
)
Hmmm...
Interesting. In any event I've picked up a few, including one on one of my AMD old timers (251595}.
So far so good there. After one and a half hours of run time I'm projecting about a 300 Ksec execution time (which is decreasing at this point).
Alinator
I'm having a lot of trouble
)
I'm having a lot of trouble actually getting these tasks at the moment. Very rarely, one of the required files will begin downloading - at which point it finishes quickly - but most of the time they just sit there until BOINC decides to try the next file in the list. Is this simply a result of server-wide performance issues, or an actual problem with new code?
RE: I'm having a lot of
)
Same here.
According to server status, only one out of five mirrors are up.
Michael
Team Linux Users Everywhere
RE: I'm having a lot of
)
This seems to be a common problem on our download mirrors, neither with the apps nor the main server.
BM
BM
RE: According to server
)
It's not that the mirrors are down, they just appear to be overloaded.
BM
BM
RE: RE: I'm having a lot
)
LOL...
I'd say so! If the status page is correct we can only draw from AEI-Hannover right now.
And there's no telling how long it can hold up under the onslaught! ;-)
Alinator