Travis,

Logan is right. The real problems for those of us with fast machines are twofold.

1. The estimated duration for a WU, when it is published by the project is way too long (ex. the older WUs show up at around 22 hours after a reset on my machine) After several dozen wus have completed, the DCF has been reduced to the correct amount, but it is considered too low for BOINC to allow more work.

2. The new set of WUs started last week (I38 & I39) had estimated durations out of line with the other WUs. They were about 25% longer to crunch, but the published duration was about 2x.

People weren't seeing problem #1 because we were just above the theshold of the problem until the new WUs drove our DCFs down even lower.

My suggestion is that the published duration for each WU be cut by a factor of 10. That way the fast machines will still have reasonable DCF, and older, slower machines can have DCFs greater than 1.0. Also, try to make sure that each new set of WUs have duration estimates in line with other outstanding sets.

Glenn

I'll update the code thats calculating the flops tonight, hopefully it should smooth things out.

---

I just updated the fpops estimate. Newly generated workunits should reflect the different estimate. Let me know how it works out.

---

I just updated the fpops estimate. Newly generated workunits should reflect the different estimate. Let me know how it works out.

Yep, I've got some that are estimating a whole 3 seconds. Haven't gotten to them in the queue yet tho'.

---

Calm Chaos Forum...Join Calm Chaos Now

I just updated the fpops estimate. Newly generated workunits should reflect the different estimate. Let me know how it works out.

Yep, I've got some that are estimating a whole 3 seconds. Haven't gotten to them in the queue yet tho'.

Might take boinc a little bit to adjust :)

---

I just updated the fpops estimate. Newly generated workunits should reflect the different estimate. Let me know how it works out.

Yep, I've got some that are estimating a whole 3 seconds. Haven't gotten to them in the queue yet tho'.

Might take boinc a little bit to adjust :)

Oh yeah, I'm used to that. ;)

---

Calm Chaos Forum...Join Calm Chaos Now

I just updated the fpops estimate. Newly generated workunits should reflect the different estimate. Let me know how it works out.

It seems to have worked at least on my C2D lappy so far: the estimated time to completion was now 4 sec but it has gone up already to 6:57 min after the first WUs being crunched.
But my DCF on that host is still 1.014688 (before it was 0.01) - so that seems fine!
Didn't check my other boxes yet, because it's 1:15am here (German time) and I have to crunch my zzz unit now. *grin*

---

Lovely greetings, Cori

Yep - looks like it has been fixed.


Checked a couple of boxes and they are requesting new work.


Thank YOU LOGAN (my awesome team mate) and Gleng - for figuring out what the problem was.

---

.

I just updated the fpops estimate. Newly generated workunits should reflect the different estimate. Let me know how it works out.

Just looked to the WUs and see you have set it to the value I send you. But to be correct, the single stream WUs are worth ~1.25 TFlop, the ones with two streams more like ~1.9 TFlop. If you look at the runtimes for these WUs, you will see more than 50% increase for the WUs with two streams. At least if you look at the runtimes of some (the fastest ones) optimized applications ;)

And btw., SETI is using single precision calculations. So one flop here (double precision) should be worth more than over there. Do you know the official point of view (David Anderson) for comparing single precision flops (SETI) with double precision flops (MW)?

I just updated the fpops estimate. Newly generated workunits should reflect the different estimate. Let me know how it works out.

Just looked to the WUs and see you have set it to the value I send you. But to be correct, the single stream WUs are worth ~1.25 TFlop, the ones with two streams more like ~1.9 TFlop. If you look at the runtimes for these WUs, you will see more than 50% increase for the WUs with two streams. At least if you look at the runtimes of some (the fastest ones) optimized applications ;)

And btw., SETI is using single precision calculations. So one flop here (double precision) should be worth more than over there. Do you know the official point of view (David Anderson) for comparing single precision flops (SETI) with double precision flops (MW)?

Actually, what I did was calculate the number of times the calculate_probabilities function was invoked (since this is doing the vast majority of the work), then calculated the number of fpops in there.

I counted multiplies as 1, divides as 5 and sin/cos/pow/exp/sqrt as 10. Pretty gross simplification but it looks like it's a decent estimate -- if anyone has better values for these please let me know :)

I don't know what Dave A's stance on single vs double prescision flops is. It seems like the estimation only has to be a rather loose estimate (or very loose considering our previous ones).

---

and sin/cos/pow/exp/sqrt as 10. Pretty gross simplification but it looks like it's a decent estimate -- if anyone has better values for these please let me know :)

These instructions are far more expensive, especially when no native CPU instruction for it exists and they are implemented in the mathlib of your compiler. I've counted directly the needed floating point instructions in the assembler of the GPU code. These figures should be quite exact. I've send it to you already some hours ago. Actually together with two formulas how to deduce the count for arbitrary parameters of the WUs ;)

It seems like the estimation only has to be a rather loose estimate (or very loose considering our previous ones).

My comment was more targeting the calculation of the credits based on the same scheme as SETI is doing. For runtime estimate you are right, it has to be only a loose fit.

I am seeing this wonky behavior on at least one of my rigs too........

Runs the cache down until the very last WU has been crunched, and then finally requests more work......

uuuhhhh... it's back!
one of my rigs stopped requesting work...

---

mic.

I am seeing this wonky behavior on at least one of my rigs too........

Runs the cache down until the very last WU has been crunched, and then finally requests more work......

uuuhhhh... it's back!
one of my rigs stopped requesting work...

Hit the update button.....I just got work on several of my rigs..

---

I am the Kittyman.

Please visit and give a Click for Seti City.

LOL - as if boinc cares about users hitting buttons...

Sat 14 Feb 2009 01:37:01 AM CET|Milkyway@home|Reporting 2 completed tasks, not requesting new tasks

---

mic.

LOL - as if boinc cares about users hitting buttons...

Sat 14 Feb 2009 01:37:01 AM CET|Milkyway@home|Reporting 2 completed tasks, not requesting new tasks

I would guess it's a workshare issue then....if you are running more than one project on the rig.

---

I am the Kittyman.

Please visit and give a Click for Seti City.

LOL - as if boinc cares about users hitting buttons...

Sat 14 Feb 2009 01:37:01 AM CET|Milkyway@home|Reporting 2 completed tasks, not requesting new tasks

I would guess it's a workshare issue then....if you are running more than one project on the rig.

100% MW this one.

might need a reset...

well whatever, I'll go to bed now and look if boinc likes some new work tomorrow...

---

mic.

LOL - as if boinc cares about users hitting buttons...

Sat 14 Feb 2009 01:37:01 AM CET|Milkyway@home|Reporting 2 completed tasks, not requesting new tasks

I would guess it's a workshare issue then....if you are running more than one project on the rig.

100% MW this one.

might need a reset...

well whatever, I'll go to bed now and look if boinc likes some new work tomorrow...

Well, if you have no work cached, you can do a reset without losing anything, and it won't delete your opti app, if you are using one....

So try THAT button....LOL.

---

I am the Kittyman.

Please visit and give a Click for Seti City.

Go no work, hit 'update' and got 12. So they might be sparse yet.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Well, if you have no work cached, you can do a reset without losing anything, and it won't delete your opti app, if you are using one....

So try THAT button....LOL.

I demand a "Go to sleep and wait"-button!
Sleeping and doing nothing fixed the problem.

---

mic.

Well, if you have no work cached, you can do a reset without losing anything, and it won't delete your opti app, if you are using one....

So try THAT button....LOL.

I demand a "Go to sleep and wait"-button!
Sleeping and doing nothing fixed the problem.

Speaking of a "go to sleep and wait" button. I think i just pressed it :) see ya'll tomorrow.

---

Well, if you have no work cached, you can do a reset without losing anything, and it won't delete your opti app, if you are using one....

So try THAT button....LOL.

I demand a "Go to sleep and wait"-button!
Sleeping and doing nothing fixed the problem.

Speaking of a "go to sleep and wait" button. I think i just pressed it :) see ya'll tomorrow.

Rust never sleeps..........

---

I am the Kittyman.

Please visit and give a Click for Seti City.