Why the short due date with long workunits?
18 May 2007 0:36:30 UTC
Topic 192760
(moderation:
I can see LHC@HOME doing it - they are designing something. But Einstein is processing data - just like seti. However, the new workunits can be long (the next one queued sez 64 hours) and the due date is short. the one in the queue is due on 5/31. Well.. I have some seti WU's too. All with due dates in the 6/9 to 6/11 range. Their durations are 11 to 15 hours. So why does einstein@home seem so unfriendly? Always cutting to the front of the queue with short due dates and hogging the cpu too for long periods? I know about STD and LTD and I know it evens out - but it seems darned unfriendly and more than a little opportunistic.
Why the short due date with long workunits?
)
Why indeed? I downloaded a new work unit yesterday that is due on 5/30 but shows 347 hours left to completion! If I run my computer 24 hours a day, it still won't make the deadline!!
because the other side of the
)
because the other side of the coin is people whining that they're going to have to wait two whole weeks to get credit for a WU because the idiot they're parterned with isn't actually returning any results.
RE: Why indeed? I
)
the largest potential WUs (acording to a graph posted by Bernd) are about 630 credits, noone's seen any above 530. Unless your machine spends alot of cpu time doing other stuff than crunch, you should be able to get a 630credit WU completed within the deadline at 24/7.
Part of the issue with the current sizes is that a new app design has been required due to the fact that the amount of analysis needed is growing with the 6th power of the amount of data acquired (eg 2x data = 64x work). To deal with this problem, the new app is designed to focus in on the areas with the strongest potential signal for additional crunching time instead of doing the same amount of work everywhere. The new app turned out to have a few hard to isolate bugs when released and as a result of the ongoing effort spent trying to fix them the app hasn't been optimized the same was the old s5r1 application was.
RE: because the other side
)
Let'em whine. With the sudden increase in length with S5R2, I would think that an extended deadline is in order. While it is inevitable that old machines will sooner or later be unable to make a useful contribution, I see no reason not to utilize the work their owners are willing to donate as long as possible.
OTOH, the project does have to balance this against the number of whiners who may quit crunching einstein because they don't get immediate gratification. While my personal bias favors those willing donors who, for whatever reason, wish to run slow machines, the amount of science done may be maximized by deadlines that exclude these slow machines in order to keep the whiners happy.
The possibility of allowing users to select between long and short deadlines suggests itself, but so does the possibility that this would be an administrative nightmare.
I too feel that the work
)
I too feel that the work units are too large, given the short deadlines that go with it. That way a lot of work is getting wasted. I recently lost more than 1000 credits as I was away for a few days & the computers failed to meet the deadline. I personally feel that the workunits should not be more than 100 credits long.
I can understand what you
)
I can understand what you mean. I don't really like it, personally, because I always have about a week's worth of credit pending already (I'm running two relatively fast boxes with high res shares), but that is a minor annoyance compared to not being able to make the deadlines. And I believe that is the case for quite a few people atm. Had a P3 make it just barely (about 20 hours before the deadline) myself... okay, that was only because it runs very short times compared to most other boxes here, but there are both bigger WUs and slower computers out there...
I had a machine finish its
)
I had a machine finish its workunit one day after the deadline. It validated just fine and normal credit was awarded.
One day after is pure luck,
)
One day after is pure luck, there you get the credits.
Four or five days after you get nothing.
RE: I too feel that the
)
On a fast machine, a 100 credits WU will finish in only about 3 hours if the host is doing 100% Einstein«Home, I think. So it will need to receive 8 WU per day **and per core** .
This increases the number of interactions and the valume of data transmitted (I don't think that 100 credits units would be ony a 5th the size in bytes as compared to a 500 credits WU).
So there's a server side that has to be taken into account as well.
CU
BRM
Three hours? Yeah, sounds
)
Three hours? Yeah, sounds realistic. I'm surprised myself that it's so short... My Core Duo (okay not the fastest out there but certainly not a "slow" host either) does a little under 15 credits/hour (running Linux, but we had that in another thread ;-) ) which would mean about 7 hours for a result... okay, but it has two cores, which statistically means it has to get a new WU every 3.5 hours... Take these numbers, think of the Xeon Quads out there, and I think you can understand why the new WUs are so huge... I can.