Good Work!
Average turnaround time 0 days

Timmy

---

On the alpha servers new turnaround code is/will soon be tested.

Here's some of the code...

Regular Result: (validator)
double turnaround = result.received_time - result.sent_time;
if (host.avg_turnaround == 0) {
host.avg_turnaround = turnaround;
} else {
host.avg_turnaround = .7*host.avg_turnaround + .3*turnaround;
}

Overdue results:
if (res_item.res_report_deadline < now) {
...
penalize_host(res_item.res_hostid, wu_item.delay_bound); // In seti@h, delay_bound = 14 days
}

---

If I'm reading that right (I doubt it), a late return locks the machine out for downloads for two weeks. If it is right, I like it.

Just a small gripe, instead of the "pending" under the credit granted column, could it display results in ( for example 1 of 3, 2 of 3, or 3 of 4)? It would just make for a quick reference, instead of having to check it individually.

---

Still looking for something profound or inspirational to place here.

>If I'm reading that right (I doubt it), a late return locks the machine out for downloads for two weeks.

No, it adds 30% of 14 days to turnaround time.

So, if your turnaround were 1.0, and you had ONE overdue, it would take you 10 WUs (at 1.0) to get back below 1.10. (note: 10 returned/validated WUs)

TWO overdue in a row - requires 11 WU returned.
(Try this formula in Excel: =B4*0.7+0.3*A5 and repeat it for most of the B column. Put the return times in the A column)

Ok... I guess I'm just a little dense here, but I still don't see what this is supposed to do. If a client returns a WU late it adds 30% to the turnaround time. For one, I'm not sure what is being refered to with the term turnaround time. Also, what good will come of adding the 30% to the turn around time?

Thanks for clearing this up for me.

Jim

---

>I still don't see what this is supposed to do.
>

See This post.

---

thank you for that link. That helps to answer part of my question. It explains part of the benefit of this system. I like the idea, also.

I still don't understand what will happen when a work unit is late (ie: passed the 14 day mark). Is it going to take the actual turn around time of the machine and tack on an additional 30% and use the new value in the system mentioned in this post? And, if this is the case, then how is this going to help the system? How will this really penalize the host? Will it get fewer WU based upon the new value? If this is the case, then it would be good, because fewer WU would time out on this particular host.

> >I still don't see what this is supposed to do.
> >
>
> See
This post.
>

---

If a WU is late (for example machine was left off 14 days, or had too many WUs delivered, or user reset project)...

The BOINC server will take the deadline time (for seti this is 14 days), multiply it by 0.3 (30%) and add it to 70% of the existing turnaround time.

new_turnaround = old_turnaround * 0.7 + 14 * 0.3

Why?
Well the system that caused a result to go overtime has burdened the project.
Caused the servers to keep other user's returned result files on hard drives while waiting. Caused the database to keep records on this WU longer than it would have (if result were returned in time). Caused other users to delay getting granted credit.

Whats the effect
Well that hosts turnaround time gets bigger.

Right now, without prioritized scheduling turned on, it only means the number gets bigger. In the future it means that host gets given WUs along with other machines that take longer to return WUs.
(Note: These other machines might have a longer "connect every __ days" setting, and might never go overtime)

Will it stay that way?
Depends.
If system keeps going overtime the turnaround number will max out at 14.
If system then returns regular WUs, the turnaround number will gradually approach the regular turnaround time.

Example
System is set to "connect every _1_ days".
Turnaround number will be at or near 1.0
(Work systems, which are off for weekends will have periodic 3 day returns)
Overtime WU is not returned on time.
Turnaround number = 1.0 * 0.7 + 14 * 0.3 = 4.90
All following validated WUs are approx 1.0.
Here is the turnaround number over time (for each validated WU)
In the left 2 colums, one result was overdue, in the right 2 columns 3 results were overdue.

WU   avg_Turnaround      WU   avg_Turnaround
1    1.0                 1    1             
14   4.9                 14   4.9           
1    3.73                14   7.63          
1    2.911               14   9.541         
1    2.3377              1    6.9787        
1    1.93639             1    5.18509       
1    1.655473            1    3.929563      
1    1.4588311           1    3.0506941     
1    1.32118177          1    2.43548587    
1    1.224827239         1    2.004840109   
1    1.157379067         1    1.703388076   
1    1.110165347         1    1.492371653   
1    1.077115743         1    1.344660157   

Hope this helps.

Ah!
This new add to comp summary is great. :D Now we can see that downloading 200 WU's even by a P4 HT 3.4 sucks. Their average turnaround is about 6-7 days :/ i dont know why people download so much WU's since SETI is very stable now and there's no need to be afraid that computers wont have work... Greets =)

---

Benher,

Yes, that does help out a lot. Thank you for spelling it out for me. I think I was kinda on the right track, but now I have a much better grasp on things.

Jim

---

Even though SETI@Home on BOINC is pretty stable now. This is still somewhat of a historical accident. I tend to agree that long queues are not that necessary, when there are only two projects to participate in; well, there is still a fairly high chance that you can run dry of SETI@Home work.

Somewhat worse is the fact that if you do run dry of SETI work, you proably will not have enough work from cp.net to keep all your processors busy (most of my dual processor machines have only one cp.net WU.

When any one of Predictor@Home, LHC@Home, and Einstein@Home go back on-line I will probably revisit my recommendations for a work queue of 4 days. Presupposing that they stay on-line!

:)

---