I would like to see tasks being sent to computers that have similar average turnaround times. Why should someone with a computer that turns files out in just over half a day have to wait 7 or 8 days for credit, due to the matching task being sent to a computer with a much longer average turnaround. If files were sent to computers with similar turnaround times, wouldn't there be fewer pending credits, since most tasks would then be completed at about the same time?

Just my two cents.

Turnaround times can be very misleading. Fast systems that aren't online very often will have longer turnaround times than a slower system that is online all the time. Or a fast system that spends most of its time crunching for other projects may also have a longer turnaround time than usual.

Moreover, all the data we're processing is many light-years old, should it really matter how quickly your credits roll in if its a few weeks? Just think of it as cash in the bank.

Personally, I don't think hosts should be discriminated against simply because people want credits faster. The science is the most important aspect of the project.

Just my $.02


[funny]: Why is it that you can give two cents, but its only a penny for your thoughts? Where does that other penny go? :-D

---

as to the other penny have you never heard of taxes

---

as to the other penny have you never heard of taxes

I knew it! Dang government is taxing me on my thoughts now too! LOL :)

as to the other penny have you never heard of taxes

I knew it! Dang government is taxing me on my thoughts now too! LOL :)

maybe claim it on income tax refund? XD

back to the subject, i agree computers with fast turn around times should be prioritized, but imo it would cause problems on the server backend. there would be more cpu labor, so to speak, to find a "matched pair" of pcs. but on the other hand, if they were both returned at about the same time, disk usage would go down because they wouldnt be lingering there waiting to be analyzed and credited. maybe as an interim trial, use an option to prefer fast computers for "rechecks" in the event the two original computers come back with different results(if it doesn't already do this)

...back to the subject, i agree computers with fast turn around times should be prioritized...

It's not a thing of "prioritizing"; the OP spoke of matching slow computers with slow wingmans and fast with fast ones. But your argument of server overhead catches anyway.

...there would be more cpu labor, so to speak, to find a "matched pair" of pcs...

Gruß,
Gundolf

---

Computer sind nicht alles im Leben. (Kleiner Scherz)

SETI@home classic workunits 3,758
SETI@home classic CPU time 66,520 hours

...back to the subject, i agree computers with fast turn around times should be prioritized...

It's not a thing of "prioritizing"; the OP spoke of matching slow computers with slow wingmans and fast with fast ones. But your argument of server overhead catches anyway.

...there would be more cpu labor, so to speak, to find a "matched pair" of pcs...

Gruß,
Gundolf

It is not matching slow computers with slow computers and fast with fast. It is matching turn around times. A fast computer that is only connected to the network once a week may have a longer turn around time that a slower computer that is connected all the time.

---

BOINC WIKI

It is not matching slow computers with slow computers and fast with fast. It is matching turn around times. A fast computer that is only connected to the network once a week may have a longer turn around time that a slower computer that is connected all the time.

You are right, my wording wasn't correct, but what I meant is the effective speed of a host, which roughly is the reciprocal of the turnaround time. :-)

Gruß,
Gundolf