I noticed that seti crunches units out of order...units are due prior to the ones being worked...is there a fix for this, or should I just ignore it?

thanks!

---

"Two things are infinite: The universe and human stupidity; and I'm not sure about the universe." - Albert Einstein

Just ignore it as work is done on a first in first out basis unless time due to report comes into play.

Cheers.

---

Units are crunched in FIFO - first in first out, unless local simulation predicts deadline misses for tasks, in which case those are moved to EDF -estimated deadline first - showing as 'high priority' on the client.

In other words it's a feature.

There are indeed workarounds, but under 'normal' circumstances they are completely unnecessary.

P.S. a FAQ, a FAQ a (smallish) kingdom for a FAQ.

---

Carola
-------
I'm multilingual - I can misunderstand people in several languages!

Cool, thanks all!

I was just curious and hadn't seen anything about this in the past.


Kevin

---

"Two things are infinite: The universe and human stupidity; and I'm not sure about the universe." - Albert Einstein

Units are crunched in FIFO - first in first out, unless local simulation predicts deadline misses for tasks, in which case those are moved to EDF -estimated deadline first - showing as 'high priority' on the client.

I believe that should be Earliest Deadline First, a.k.a "Panic Mode".


-- Tony D.

---

I believe that should be Earliest Deadline First, a.k.a "Panic Mode".


-- Tony D.

Even better would be: the smallest ["time till deadline" - "estimated chrunchtime"] first, and maybe if the value is negative abort without wasting chrunch time trying.

---

Even better would be: the smallest ["time till deadline" - "estimated chrunchtime"] first, and maybe if the value is negative abort without wasting chrunch time trying.

Problem there is that if we get stuck in a shorty storm (many VHARs) the older longer WUs would not get done in time.

---

PROUD MEMBER OF Team Starfire World BOINC

Even better would be: the smallest ["time till deadline" - "estimated chrunchtime"] first, and maybe if the value is negative abort without wasting chrunch time trying.

Problem there is that if we get stuck in a shorty storm (many VHARs) the older longer WUs would not get done in time.

Well you would have two variables there, you would just have to make sure the "time till deadline" part of the equation weighs much more heavily. That way if it had to pick between two needing to be crunched with the same due dates and same size it would pick the correct one just as well as it would pick between one due tomorrow that is large and one due two weeks from now that is smaller.

Something like:
Time time due 1 day = 100%, 2 days 50% etc. all the way down to .001. Time simply the amount of seconds.

Two work units:
Wu1 = Due in two weeks and takes 100 seconds.
Wu2 = Due in 3 days and takes 1000 seconds.

(Time due percent) x (Time needed to complete) = weighted value.

Wu1: (7.142857142857143) x (100) = 714.286 (Rounded to the thousandth)
Wu2: (33.33~) x 1000 = 33333.33~

Then it would pick the one due in 3 days. Of course something like this would only work if they tighten up the formula on figuring how much each computer can crunch in a day, and then it would become even more problems because not everyone runs their computers around the clock. You would need a proven track record over say, 3 months, to see what the average per day works out to and adjust how many units are sent. It would also involve taking those same numbers and assigning which units are crunched by either the cpu or gpu on the server side. You could probably start people small and only send two unit at a time and continue sending one per upload over a 24 hour period and keep a running total. But then you are talking about an extra sever or more to keep track of that, plus the database admin hours, the scripting, people dropping out a leaving WU's hanging and on an on an on.

I think the way they have it figured out works pretty well. I sometimes don't let my main machine crunch around the clock due to work or gaming or other things and none of my machine have ever turned in a late work unit because of the machine. Let it do it's thing for now, I'm sure like anything else over time they will find better or more efficient ways of controlling it.

---

Traveling through space at ~67,000mph!