I thought I'd start a thread for observations, comments, and discussion regarding GW S6 Lineveto extended.
There was an announcement in the Technical News forum posted on January 14, 2013.
While the Einstein server status page has been showing a rapidly growing amount of extended work, at the moment of this posting just 630 tasks show as valid, and this is up hugely from yesterday--so it is early times.
Regarding availability: For my hosts, the Einstein preference for each of the four locations (often called venues) for extended initially showed as off. This might be a side effect of my previous preferences--or might be general. If you want to be enabled to get extended, best check your preferences.
Also regarding availability, for most of the last 24 hours all five of my hosts have been configured to accept extended, and for more than twelve hours two have been configured ONLY to accept extended as CPU work, with the other three accepting either flavor of GW LineVeto but not Gamma-ray pulsar. In all that time, just one extended job has been assigned to any of my hosts (and that one was to one willing to accept either).
So, for the short term--don't expect much. Just because the server status page shows several thousand "tasks to send" does not mean your request will be honored.
The predicted execution time for the single extended WU I've downloaded is the same as for the previous LineVeto work on the same host.
Copyright © 2024 Einstein@Home. All rights reserved.
extended GW comments
)
An update. I forced (by suspending other work) the single downloaded extended (1.04) WU to run, and shortly after started a conventional (1.13) GW LineVeto WU on this dual-core host.
When the host reported completion of the extended WU, it received two more, though it remains true that none of my other hosts have received any yet--so locality scheduling is probably part of the difficulty in getting a first WU on a host.
My recent sample size (three) of conventional LineVeto work on this host is small, but the times for the the new extended unit are outside the range low on both elapsed time and CPU time.
elapsed time was 6:25:03 on this dual-core Conroe for extended, vs. about 6:51:00 on conventional
CPU time was 6:22:41 vs. about 6:47:00.
So it could be, at least on this host, that the new extended work will run a bit faster than the late conventional work, perhaps about 6%.
RE: ... it remains true
)
When a client asks for work, it documents (in the sched_request) all the large data files it already has. If there are still tasks for existing data, there is no reason for the scheduler to want to send you different data. As soon as the scheduler doesn't (at that instant) have any work for existing data, it's likely to send you a whole new set in the new run. In another couple of days, everybody will be starting to get files and tasks for the new run when the remaining 130K tasks for the old run are exhausted.
Cheers,
Gary.
With five hosts trying to get
)
With five hosts trying to get extended work since shortly after I started this thread, only one new one has succeeded, even though most had multi-day queues and I set them only to accept extended until their queues ran down to at or near zero.
So my sample size on the possibly faster execution times for extended is only up to two hosts. The second also appears to show a modest speedup, more like a little below 5% instead of a little above 5% on my first.