New GW search S6LV1
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4312
Credit: 250417614
RAC: 35226
5 Mar 2012 10:46:31 UTC
Topic 196212
(moderation:
The current GW search S6Bucket is coming to an end. We already started to generate all the remaining workunits and put these in the database.
As the remaining workunits are scattered over the whole frequency band, as usual our locality scheduling isn't very effective anymore, and the download volume for processing GW tasks increases. If you are on a slow (or expensive) internet connection, you may want to back off Einstein@Home for a few days.
Preparations for the next 'run' called S6LV1 (data from sixth LIGO science run, first run using 'line veto') are already finished, the first S6LV1 tasks should be shipped in just a few days. As this run uses the same data files, this should then lower the required download volume again.
BM
BM
New GW search S6LV1
)
I've noticed on the "Applications" page that there's no 64-bit Linux version of this app. Do you plan to add one, or do I need to install the 32-bit libraries on my machines that don't have them?
RE: I've noticed on the
)
Never mind. I'm installing 32-bit libraries now.
The two hosts for which I so
)
The two hosts for which I so far have finished S6LV1 both take longer to finish a task than on the previous GW work. Initial indications suggest 10% or a bit more extra time.
The hosts are both Windows XP Pro machines, one a dual-core Conroe, the other a quad of the Penryn generation.
i too am experiencing
)
i too am experiencing increased run times, although i'm seeing S6LV1 tasks taking anywhere from 5% to 32% longer than S6GC tasks. i'd say on average they're taking ~%18 longer to run. i to am running WinXP (32-bit though). of course my S6LV1 sample size is extremely small b/c the tasks have only been available for a few days now, so take my estimates with a grain of salt.
We have stopped generating
)
We have stopped generating S6LV1 workunits for now to investigate a 'scientific' problem in the app (the code apparently differs from the formula it should implement). We probably need to restart the run, most likely on Monday next week. It is still not clear whether we need a new application (version), or just need to change the command-line arguments to achieve the same effect. But in any case the timing behavior of the S6LV1 tasks will most likely be different after the restart.
BM
BM
The "locality scheduler", the
)
The "locality scheduler", the part of the scheduler that serves GW work (S6Bucket and S6LV1) was causing problems, so I turned it off (late Thursday) until I could analyze and fix this in the code. I did this today. Currently the workunit generator for the S6LV1 re-launch is initializing (which takes a few hours), the "locality scheduler" will be turned on again afterwards, later today or early tomorrow.
BM
BM
RE: in any case the timing
)
Yes. My small initial sample of SL6V1B shows times materially shorter than SL6V1A on the same two hosts mentioned before, and not so far distinguishable from the previous S6BucketA recent work on those hosts.
All of these tasks are
)
All of these tasks are failing on my linux hosts. May be a permission error for this app other Einstein tasks are running fine on these hosts.
process exited with code 22 (0x16, -234)
execv: Permission denied
This seems to be an issue
)
This seems to be an issue with the new BOINC Core Client 7.0.20. We do see this on Macs, too. I'm in contact with BOINC Devs.
BM
BM