51 hour runtime?

Sorry, Jord, but I just checked my CS and neither Albert nor Einstein are sending and yes I'm on 7.3.11.

compare

703

http://setiathome.berkeley.edu/

with

611
http://einstein.phys.uwm.edu/

So, no idea what happened to your CS - might you be looking at the remains of an old bug?

Einstein don't even use APR - and DCF can be anywhere in that scenario.

Ok, let me try to be coherent to our OP :D
[without using too many nerd words. um that may be difficult]
ok with nerd words first.

the initial estimate of a task on a host depends on rsc_fpops_est, APR and DCF. The latter only on projects that use one or the other.

While the task processes a not very good equation calculates remaining time according to initial time and actual runtime. With new boinc [actually you might want to update to latest recommended] after about 87% the actual runtime will drive the estimate of time remaining.
After the task has processed, DCF gets adapted - DCF being horribly in adeqwuate system in the first place and even worse when more than one app run.

DCF for different apps tend to be differnte - which is why David invented APR (and CreditNEw along with it moving his DCFs to the server, but that's neither here not there)

OK, Einstein. let me see 60k for a GW... so about the same as me, and my dcf is close to 3 - probbaly coming down from the F#3 I've been doing lately.

So, you started on a GW. gets send out with an estimate of what amounts to say 5h - after one task DCF shoots up to adjust and the next task comes in at some 17h. so far so good.
Now, a F#3 turns up. the initial estimate is around 10h. however your DCF is 3 so 3*10 - 30. now f#3 actually take about 20h as you found (and neevrmind that I had one run through in 6h) so DCF goes down a fraction.

depending on what tasks you get DCF can be anywhere - initial estimates will be lousy especially if you swicth between types - it shoots up and only VEEEEERY slowly comes down. It was hopless 4 years ago and it hasn;t gtten betrter.

Well, at least this being Einstein, with any luck in a year or two (or 5) you may be looking at the only project that has working credit and APR.

Sorry you were saying? What was the question again?

So, you can't go by the initial estimate. best thing is to extrapolate from the % and runtime - Einstein tasks tend to be pretty linear (unlike SETI) - and do the maths if you can return the task in time.
Also, just keep a record of how long the different types take on your rig and then you can use that figure for future tasks instead of the buggered boinc figure.

If I didn;t make any sense to you don;t worry - I'm currently not making much sense to myself either. I know what I know but it's exceedingly difficult to find the right words. And you can keep the typos, they are free to a good home.

Edit: I see Jord found that he must have been looking at the wrong project :D

edit2: I don;t seem to have an Avatar yet. Any of my friends want to suggest one that fits? No, sorry, the rolling pin gives the wrong impression.

What The Lads are chatting about is a special sort of magic invented by the Good Wizards Of IT over at Berkeley Castle. When the spell is cast it makes a neat sound : 'boinc'. Some of the more trained ears can distinguish a 'Boinc' from a 'boInc', which can be fun if you're into that sort of thing, and may detect when A Client isn't being served properly at mealtimes.

[ There are other noises, most of them pretty rude on the day, which are not often spoken of ..... ]

Cheers, Mike.

( edit ) It is rumored that the Evil Wizards Of Hannover Dungeon have been altering the Spells Of Serving .....

I am German. Ve don't do ze humour zing ;)

Let me try again to explain more coherently. Probably more than you actually asked for, but it may help to clarify things.

I'm afraid I have to add a little BOINC history lesson.

When we started out, a project used to have only one application. SETI had MB and Einstein had GW (gravitational wave).
Now the task that you get gets an initial estimate. This is based on a more or less good guess by the project scientist on how much processing time (in terms of calculations to be performed) the task will require.
Now your computer can be fast or slow. At the beginning BOINC doesn't know. So it goes by the initial estimate. It does try to factor in how long the task is actually taking for the estimate of the remaining time.
If your computer is slow, the task will take quite a bit longer than that initial estimate. When it is done, BOINC will try to compensate. Depending on the project it does this differently. (that's the history bit) Here at Einstein DCF is used. DCF means 'duration correction factor'. that is the factor between the time BOINC thought the task was going to take and the time that it took. That depends on whether your computer is fast or slow. Say the task started with 5h estimate. Then it took your machine 15 hours to process. that's 3x so DCF will go to 3. Had your machine only required 2.5 hours you'd eventually get a DCF of 0.5. I say eventually because DCF is made to go up fast - you take that 3x it goes all the way up - but down slow - it's cautious, it won;t go down all the way to 0.5 it will take several tasks at that fast speed to beliebve your machne is fast. it will go maybe 0.9,0.8...

Ok, understood that bit? DCF is a local compensation factor to make sure the tasks get good local estimates.

Now, DCF will have an application and host specific value. It can wobble around - it can even wobble around badly if your machine usage changes a lot and the time it spends on BOINC goes up and down. But to stay with the example, it will stay in the region of 3 as long as you get the same type of tasks.

Note 'same type'. DCF is okish if you have only one application. Now, move forward. The project decides that it wants to look at other things as well - BRP here, AP on SETI. And here's the rub. Your machine may be better at handling BRP. Let's say you take only 0.9 of the time it starts out with. Now, your DCF was at 3 from all those GWs. Along comes a BRP. lets say the initial estimate for a BRP is 2h (sorry no idea how long they really take). But your DCF is 3. So boinc thinks 'I need to multiply with 3' and gives an estimate of 6h. The BRP however doesn;t take 6h. it takes 1:45. oops. ok, DCF goes down a bit. you keep getting BRP, DCF keeps dropping until eventually it reaches the 0.9 that are the right factor for BRP. if you look, initial estimates will be dropping from 6h to 1:45. oooohkaaaayyy. Now, you get another GW. THAT will be estimated at - no not at the 15h it takes at 5*0.9 = 4:30. Ohoh. We knoe it is going to take 15h. but boinc doesn;t know. It CANNOT know. ok, the task will crunch and eventually after 15h of silly estimted time remaining, it's done. Boinc sees it took 15h so DCF goes? exactly it goes back to 3. Up fast, down slow.
So you see, with multiple applications that have different DCF the estimates will always be wrong. They might be a bit better if you just had a strech of one type especially if it's a long running one. But on the whole your DCF will be all over the place, depending on what mixture you get.

So, that's what happend on your host with that 51h estimate.
You had been running GWs and they have moved DCF to around 3 (from your runtimes). Then you got that FGRP#3 and boinc automatically assumed that it also takes 3x as long. So it started out with some 17h. Now as you saw when you let it run, it doesn't really take that long - it eventually took 18h - dcf just a tad over 1. if you'd been told '18h' you probably wouldn;t have bothered to ask us :D. but that 51h made you worry you might not return the task in time.

Actually boinc should compensate for the amount of time it actually runs (your computer is on) and not ask for work that it can't finish in time (accoring to what it belives the task will take), but I wouldn;t be too sure that really works. In my experience, boinc manages pretty well not to get into a pickle, but it may start going into EDF ('high priority'). If your host isn't really fast and not on all the time, I'd advise to choose a small setting for cache, so you don't have that many tasks on board at any given time. Makes it easier to meet tighter deadlines.

And now for the history lesson.

As I've been trying to explain, DCF doesn't really work if you have more than one application. So David (the main BOINC developer) invented APR 'Average processing rate' which is just a posh name for DCF on a per application basis and managed on the server side. Einstein has quite old sever code and hasn't yet moved to adopt APR - APR is actually being tested on Albert and when I spoke with Bernd some two years ago, it was so horrible, they didn;t really feel like upgrading Einstein to it. So for the time being we here are stuck with completely inadequate DCF. SETI however did move to APR.
So for SETI the picture is quite different. You will still get an initial estimate. This time, the server keeps track of how long your tasks actually take. and it keeps track on a per application basis. after you've completed 11 tasks the server then applies APR and sends out tasks with that new estimate. and the estimate will be okish for both MB and AP because APR (which really is just DCF) is calculated separately for MB and for AP. APR has it's own drawbacks - especially in the ramp up period because or the first 11 tasks it will stubbornly keep the initial estimate and then BANG if will give you something much more appropritate.
So, if it was running here, for 11 tasks you'd have GWs coming in with 5h and staying at 5h until they suddenly go up to 15 hours. at the same time your FGRP#3 coming in at 17h would only go to 18h.

Albert is using a mixture - there both APR and DCF are used. so first GW task - DCF to 3. after 11 tasks estimate goes up to 15 - and dcf is 3 so you get 45h.... and then dcf sloooowly goes down.
Personally I think overestimating is better - you won't get the problem that you ended up with more tasks than you can really process. underestimate and large cache? desaster.

Take home message: Keep your cache as small as possible, espiecially when starting a new project or host.
You can get greedy later when the numbers have settled. Only you shouldn't. Why hoard? There's enough to be had most of the time. And if there's not, you should be considerate of your fellow crunchers - they want a little work too.

Ok, I hope I was clear enough for at least part of this post, before I started using too many acronyms again :D

@Mike - may I borrow your sig for this one? ;)

Indeed, you are welcome. You have redeemed yourself and are now the Pinnacle Of Clarity. Or the Pineapple Of Calamity. One of those.

Cheers, Mike.