S5R2
17 Apr 2007 13:04:05 UTC
Topic 13543
(moderation:
Hi!
We're near the end of the intermediate S5RI run and thus about to start the long-awaited S5R2. Some properties of S5R2 still change faster than I can type and would be hopelessly outdated when you read them, but I'd like to give you some impression of what's more or less fixed now.
The "science run #5" of the LIGO instruments, or S5 for short, gives us not only the most sensitive data, but also the largest amount of data we ever had. This is very good in terms of science, as the sensitivity of the search for continuous signals increases with "observation time", i.e. the length of the data available.
However, with our present analysis tool, the computation time needed grows to the power of six over the amount of data. It's obvious that we need something more clever to deal with a larger amount of data, so we developed a new program which we call "Hierarchical Search". The basic idea is to first scan the parameter space with a coarse "grid" and then only take a closer look at the areas that have been detected as interesting, in a "follow-up stage". The current code is designed to do only the first stage, it had not been decided yet if we will do a follow-up stage on Einstein@Home as well or e.g. on LSC clusters.
The application we'll use for this run is all new and has never been used before. The algorithm used in the old App is still a part of the new one, and other parts have also been used before, but they have never been used in the present combination, and in particular not in a distributed computing project of that scale. We expect some problems to arise from this.
One of the issues we are still working on is some "overhead", i.e. calculations that are performed for technical reasons, but don't actually contribute to the result, thus wasting computing power.
We therefore will set up S5R2 as a short, experimental run that limits the search to parts of the parameter space where the overhead is well under control. During this short run we will improve the Application in various aspects. The results will also help us tuning the parameters for the next, larger run (probably named S5R3).
With the amount of data to be analyzed, however, also grows the amount of data to be downloaded to your machines. To save bandwidth both on your and on our side, we developed a new scheme for data files. They are split into small files of about 3MB in size (that are somewhat re-combined in the App). When there is no more work available for the data files you already have on your machine, the scheduler will try to assign work to your host that minimizes the number of files you have to download, so you should in most cases get away with a new download of only two files (~6MB).
However, a complete set of files (that will be used for many tasks you get) can consist of up to 10 files, so the initial download can be more than 40MB (including the Application and other data files that need to be downloaded only once per run). This might be not suitable for dial-up / modem users anymore.
We are running out of S5RI work, and thus as usual your clients will have to download a new data file for only a few workunits anyway, so modem users: beware.
We expect to issue the first hundrets of S5R2 Workunits some time tomorrow.
At the beginning Apps will be available only for our major platforms (Windows-x86, Linux-x86, MacOS-PPC and MacOS-x86); other platforms will follow with time. I hope to get the Apps finished before the last results of S5RI are sent out.
BM
BM
S5R2
)
Sorry, should read as edited ... MacOS-PPC and MacOS-x86. The "Intel" belonged to MacOS only.
BM
BM
RE: But one question is
)
I'm not sure I get the question right, but anyway: It's hard to tell right now. Currently we think of S5R2 being in the same ballpark as the finishing S5RI run (few months), and S5R3 will probably be designed for about the same length as S5R1 (6-12 months). But we're still playing with some parameters, and though we expect to speed up the Application during the run it's hard to predict when and to which extend we'll achieve this, which will have a large impact on the run time.
BM
BM
I'm not that much into
)
I'm not that much into assembler-programming yet, it's a bit too early (also I will try again to take more advantage of auto-vectorization this time, giving much more flexibility).
Anyway, the validator of S5R2 is one of the least tested parts, you might see credit values change or states flipping between valid and invalid of already finished tasks while we adjust it.
BTW: the first 1000 units have already been sent out, and we already discovered a problem (outdated value for estimated diskspace...).
BM
BM
sorry Mike, always nice to
)
sorry Mike, always nice to chat with you, I hope we'll pick up later. some bugs will eat me here if I don't kill them now...
BM
BM
An update on our
)
An update on our progress:
(1) We fixed a problem with the validator where some results where erroneously being marked as validate errors. I re-ran the fixed validator on these results so credit was granted.
(2) I've done some preliminary analysis of credit granted and determined that we were not awarding enough credit. For all S5R2 workunits WITHOUT a valid result (at the moment, all but 52) I have fixed this in the database. Credit awarded for the S5R2 WU will now be larger by a factor of 2.222. Note that in the past Einstein@Home has been giving out 30% too much credit compared with other projects (see BOINC cross-project credit comparison for details). The factor of 2.222 takes this into account.
Further updates will follow.
Note: we are still in the process of rsyncing (mirroring) our new S5 data to the mirror download servers. So the first S5R2 workunits all reference the Einstein@Home server in Wisconsin as the data source.
Cheers,
Bruce
RE: Thanks to Bernd & Bruce
)
Our goal is run times in the range from 6 to 24 hours. Note that some optimization is expected in the future so the apps will get faster.
Cheers,
Bruce
RE: Is there going to be
)
I have, too, on some architectures nothing newer is available. No, no limitation planned other than what existed for S4 - it should be 4.19 or newer.
Our credit system will work even with older clients. The credit is fixed for each workunit on the server side, and measurements are taken so that the claimed credit should be what is granted at the end. For this to work one needs a newer client, with older clients the granted credit may be different from what is claimed, that's all.
And btw. yes, there is a large variation between runtimes of the different WUs. In principle they get longer with higher frequency. The credit rises proportionally, so if you want to compare run times of machines, look for Workunits that claim the same credit (and use newer clients). I'll try to get some chart for WU-time vs. frequency to post it here.
BM
BM
RE: is it possible that the
)
Would be quite surprising, the output from gcc on Linux is usually slightly slower than what we get from the M$ compiler, but is not impossible. Honestly during the past weeks we have been so busy fixing mere showstoppers that I didn't do a platform / compiler comparison with the latest code versions. Thanks for pointing me to that, I'll look into it.
BM
BM
A while ago I promised to
)
A while ago I promised to post an illustration of the relation between frequency and run-time of the workunits, but got distracted a little - so here it is: PDF. Don't give too much about the absolute run-time mentioned there, which was calculated for a specific machine with an old version of the code and under certain assumptions - this should just give you an idea of the distribution. Note that the workunit generator knows about this relation and will assign credit to a WU proportional to its expected run-time.
BM
BM
RE: Cool graph. PS you
)
I thought about that, but this graph was made before we knew how much credit to actually grant for each predicted CPU-second, and this factor is still subject to change, too, with the development of the App.
BM
BM