Petition - Deadline Relief for Longest Results

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9,352,143
RAC: 0

Agreed, 3 weeks brings the

Agreed, 3 weeks brings the majority of the work within the window for my K6-2/500's, but the K6/300's will still not make it for the high end template frequencies.

I haven't sat down and crunched the numbers to estimate what the new cutoff points are for them yet. However, the new setup should provide significant relief for many hosts.

Alinator

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 461,162,614
RAC: 40,293

RE: Agreed, 3 weeks brings

Message 70057 in response to message 70056

Quote:

Agreed, 3 weeks brings the majority of the work within the window for my K6-2/500's, but the K6/300's will still not make it for the high end template frequencies.

I haven't sat down and crunched the numbers to estimate what the new cutoff points are for them yet. However, the new setup should provide significant relief for many hosts.

Alinator

With 3 Weeks deadline, you need about 33 RAC (simplified calculation...I know, just as a very rough estimate).

I checked with boincstats.com and it seems that about 40000 hosts fall into this category.

If you want to cover 50000, the RAC goes down to 15 (!) or about 6 week deadline. So a transition from 2 to 3 weeks does a lot to allow more hosts to crunch "monsters", but an additional week (to 4 weeks) would not buy that much, IMHO.

I know, this is simplified: some of the low RAC machines are fast enough but have low RACs becazuse they are switched off for longer periods in a row etc, or are new and not yet at their full RAC-level. But you get an idea, lacking better data.

CU

BRM

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9,352,143
RAC: 0

Yep, RAC is OK for a rough

Yep, RAC is OK for a rough guessitmate as long as you take into account your usage pattern when deciding.

Usually it's better to use the CPCS (Credit Per CPU Second), the time stats, Resource Share, and the RDCF for the most accuracy in close call situations. That's what the project uses to differentiate between fast and slow hosts.

The best indicator I've found is to use my own empirical data for the Credit Rate on my hosts, but you have to be tracking that independantly over time on your own. The catch is that can be time consuming in it's own right. ;-)

In any event, I don't mind the fact there is work some hosts can't deal with under the project parameters. I just wish the scheduler would take my oldest timers seriously when they tell it, "You've gotta be kidding, right!". :-)

I guess to demonstrate the concepts we've been talking about here more clearly, I'll pull some actual numbers from mine when I do the next data logging session for them and post them.

Alinator

Slywy
Slywy
Joined: 26 Jan 06
Posts: 11
Credit: 382,413
RAC: 66

RE: Please try to limit

Quote:

Please try to limit yourselves to two questions:-

1. Are the identified frequencies appropriate?
2. What should the deadline days figure be?

I just finished a workunit that I had to do some contortions on (i.e., leave computer running during the day whilst at work, up Einstein's allocation, etc.) to finish, and it completed with only two hours to spare even then. I don't know the answer to the first question, but I suspect I really need at least 21-24 days, I think, of normal running time for that particular type of WU (about 375 credits).

Stick
Stick
Joined: 24 Feb 05
Posts: 790
Credit: 3,609,529
RAC: 4,680

RE: We just started a new

Message 70060 in response to message 70048

Quote:

We just started a new workunit generator with "dynamic deadlines". The deadlines of workunits generated from now on will vary between two and three weeks depending on the size of the wokunit (i.e. the number of templates within it, which should be proportional to the credit granted).

We'll watch it for a while, maybe we need to adjust the actual numbers.

BM

Just downloaded this WU/Result and noticed it only has a 2 week deadline. However, the unit appears to be similar (in estimated "To completion" time) to this 635 point WU processed last week. That is, if I am right about it being another "Monster", it doesn't appear that the new variable deadline generator is working as advertized.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5,354
Credit: 48,597,220,407
RAC: 57,904,290

RE: ]... it doesn't appear

Message 70061 in response to message 70060

Quote:
]... it doesn't appear that the new variable deadline generator is working as advertized.

If you have a look at the full quorum for that workunit, the result you have just downloaded is a replacement for one that has just exceeded the deadline on the computer of the previous wingman.

As the deadlines are built into the workunits, unfortunately you have been lumbered with the same deadline that the previous wingman "enjoyed" :).

You'll just have to work a bit faster :).

Cheers,
Gary.

Stick
Stick
Joined: 24 Feb 05
Posts: 790
Credit: 3,609,529
RAC: 4,680

RE: As the deadlines are

Message 70062 in response to message 70061

Quote:
As the deadlines are built into the workunits, unfortunately you have been lumbered with the same deadline that the previous wingman "enjoyed" :).

Thanks Gary! I didn't realize it worked that way.

Quote:
You'll just have to work a bit faster :).

Now, if I understand this part correctly, if I don't finish by my deadline, I just need to beat the "next wingman's" result in order to receive credit.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5,354
Credit: 48,597,220,407
RAC: 57,904,290

RE: ... I just need to beat

Message 70063 in response to message 70062

Quote:
... I just need to beat the "next wingman's" result in order to receive credit.

Yep. You can usually count on a few extra days - probably 1 day as a minimum if you're unlucky :).

However, in this particular case, it is possible that you could get no margin at all. If you look at the workunit, and ignoring the compute error result #3, your result (#4) has essentially replaced #1. #2 will exceed the deadline shortly so there could be an extra wingman added as well. If that happened (let's call him #5), if any two of #1, #2, or #5 were to suddenly submit valid results, a quorum would be formed and you would need to submit by the deadline in order to get credit.

Fun, isn't it :).

EDIT: I've just had a look at the computers of #1 and #2 and it seems there's little liklihood of either submitting any time soon. I think you and #5, whoever he turns out to be, will have the best chance of completing the quorum :).

Cheers,
Gary.

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 3,979
Credit: 205,052,741
RAC: 36,340

Unfortunately the change only

Unfortunately the change only affects the newly generated workunits, older ones will still keep the old deadline. Feel free to abort the Task if you feel you can't meet the deadline.

(Gary, I'd like to contact you individually. I wrote two messages to the eMail address you registered here. Did you get them?)

BM

BM

Lloyd M.
Lloyd M.
Joined: 24 Apr 07
Posts: 24
Credit: 2,493,855
RAC: 0

RE: Please try to limit

Quote:

Please try to limit yourselves to two questions:-

1. Are the identified frequencies appropriate?
2. What should the deadline days figure be?

I've only run into one instance where I've had to manually abort WU's, because I somehow managed to get one machine hugely overcommitted. That being said, my default resource share for E@H has to be much higher (up to close to two orders of magnitude, in some cases) than my other four projects, in order to get any WUs at all.

I don't recall seeing any "monster" WUs. The WUs I have taken notice of are in the 350-450 credit range. These take approximately 28 CPU hours each (Opteron 170 2gHz, dual core, graphics enabled, Windows XP), 25 CPU hours (Athlon 64 3200+, Windows 2000, run as service) and 23 CPU hours (Athlon 64 3700+, linux, no graphics).

Aside from that one instance of somehow managing to get one machine hopelessly overcommitted, meeting deadlines is never a problem. To the greatest extent possible, I run everything 24/7.

I have a Celeron 400, and even with an optimized SETI client, it only ever managed about 25 RAC. I decided it wasn't worth the heat generated and the electricity to run it. Though I never even tried it, I wonder about the wisdom of running E@H on a machine that slow. I suppose if someone offers, one shouldn't turn them down. On the other hand, do we really want to set people up for failure and frustration? That one time I did get overcommitted, it was a drag to "lose" WUs that took so much time to try and process, only to see them get downloaded to other hosts becaus I barely missed the deadline.

If there is some simple way to make sure that slower machines only get the "easiest" WUs, that might lower the stress level of people that want to help, but only have modest computing resources. I don't know if there are system requirements published, and it might be worth telling people how much CPU they need (running for how many hours a day) to have any reasonable expectation of meeting deadlines.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.