0zzF4|\| wrote:

So ultimately what this really boils down to is that you want faster computers to be the partners for faster computers simply so you can get your credit faster.


Why should I be in favor of a system that caters to any group based upon their insistence on getting credit faster?


Unless I can hear sound, scientific reasons (and please, don't mention less workunits clogging up the database as a scientific reason), I can so no reason to support such a cause.

The motivations are all wrong, IMO.

Psychology and Sociology are also sciences, and although I partially agree with your last statement I see no reason to summarily dismiss any idea for making participants happier. Might happier participants donate enough to keep the project alive?

As others have noted, the potential for cheating means the idea as stated will absolutely not be considered by the BOINC developers.

There have been a couple of times when the idea of pairing hosts with similar turnaround time has been discussed, and as long as the classification were done so each class had many thousands of members, that approach would not encourage attempts to cheat. The simplest even division is 2 classes, hosts with shorter/longer turnaround time than the "Result turnaround time (last hour average)" shown on the Server Status page.

The implementation of that idea could probably be done with the Homogeneous Redundancy framework, but would require a new type, achieved by "You can modify the pre-defined HR types, or add your own, by editing the file sched/hr.cpp". It would impose an additional burden on both the Scheduler processes and the BOINC database, though.

                                                                 Joe

No.

Psychology and Sociology are also sciences, and although I partially agree with your last statement I see no reason to summarily dismiss any idea for making participants happier. Might happier participants donate enough to keep the project alive?

While psychology and sociology might be sciences, and it might be debatable whether SETI@Home is classified as being part of either of those types of sciences, I would argue that SETI@Home is not, hence what I wrote.

If it takes people to get their credit faster to donate, then consider me a former member.

0zzF4|\| wrote:

So ultimately what this really boils down to is that you want faster computers to be the partners for faster computers simply so you can get your credit faster.


Why should I be in favor of a system that caters to any group based upon their insistence on getting credit faster?


Unless I can hear sound, scientific reasons (and please, don't mention less workunits clogging up the database as a scientific reason), I can so no reason to support such a cause.

The motivations are all wrong, IMO.

Psychology and Sociology are also sciences, and although I partially agree with your last statement I see no reason to summarily dismiss any idea for making participants happier. Might happier participants donate enough to keep the project alive?

As others have noted, the potential for cheating means the idea as stated will absolutely not be considered by the BOINC developers.

There have been a couple of times when the idea of pairing hosts with similar turnaround time has been discussed, and as long as the classification were done so each class had many thousands of members, that approach would not encourage attempts to cheat. The simplest even division is 2 classes, hosts with shorter/longer turnaround time than the "Result turnaround time (last hour average)" shown on the Server Status page.

The implementation of that idea could probably be done with the Homogeneous Redundancy framework, but would require a new type, achieved by "You can modify the pre-defined HR types, or add your own, by editing the file sched/hr.cpp". It would impose an additional burden on both the Scheduler processes and the BOINC database, though.

                                                                 Joe

So something sort of like starting with "Class 1" for the slowest machines. Then machines could be paired with either the same class, +/- 1 , or +/- 2. New classes could be added as newer hardware comes out over time.
Then I wonder would the whole machines be assigned a class or would each kind of hardware, like the CPU & GPU, get their own class.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

This might be a different discussion if the project had servers with extra capacity, the bandwidth to support them, support staff on tap 24/7....etc. etc. etc..

Right now, I don't see anything happening that would increase the load on servers or staff.

I'd be happy just to see the Cricket graphs maxxed out for a week or two at a time with work in and outbound.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

The real problem is people who take large queue work loads that take weeks to work though. If you are going to pair wingmen, then you need to do it by the average turn around on a work unit. Because I only set about two days of queue I should be paired with somebody who can turn a work unit around in two days. My wingman could be somebody who takes two days to turn around a single work unit or a super cruncher who processes a thousand work units a day.

If you run a large queue that takes many day to turn over, you are part of the problem and you shouldn't complain about your wingman. On the other hand, if you turn your work units around in a few days, you do have an issue.

I just do SETI for the fun of it so I don't worry much about how fast my work units are credited but I do worry a bit when it takes several wingmen to check my work because I have seen cases were I know my work unit was processed correctly but two wingmen matched on a wrong answer leaving my credit out in the cold.

---

The real problem is people who take large queue work loads that take weeks to work though. If you are going to pair wingmen, then you need to do it by the average turn around on a work unit. Because I only set about two days of queue I should be paired with somebody who can turn a work unit around in two days. My wingman could be somebody who takes two days to turn around a single work unit or a super cruncher who processes a thousand work units a day.

If you run a large queue that takes many day to turn over, you are part of the problem and you shouldn't complain about your wingman. On the other hand, if you turn your work units around in a few days, you do have an issue.

I just do SETI for the fun of it so I don't worry much about how fast my work units are credited but I do worry a bit when it takes several wingmen to check my work because I have seen cases were I know my work unit was processed correctly but two wingmen matched on a wrong answer leaving my credit out in the cold.

The real 'problem' is.......
It's NOT a problem.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

i agree . i have 2 pc that burn thu work faster then most of my wingmen can handle

---

Sorry--still can't agree with this.

IMHO, one of the factors that ensures the sanctity of the project is the random deliverance of WU's to different people. Setting anyone as a pre-set receiver of a specific set of WU's or WU's from a select group of people will eliminate this critical portion of the service.

It also will make some people feel less valued. Fact is everyone, no matter how much they crunch, are of equal value to this project.

---

[quote]IMHO, one of the factors that ensures the sanctity of the project is the random deliverance of WU's to different people. Setting anyone as a pre-set receiver of a specific set of WU's or WU's from a select group of people will eliminate this critical portion of the service.quote]

I agree but I have a suggestion to ease off a little bit for some crunchers who are RAC maniac.

Repair tasks should have a shorter deadline and only send to fast and reliable hosts - just like at WCG. But then again server load will rise up.

After all, this project doesn't need the results pronto.

---

I agree but I have a suggestion to ease off a little bit for some crunchers who are RAC maniac.

Repair tasks should have a shorter deadline and only send to fast and reliable hosts - just like at WCG. But then again server load will rise up.

After all, this project doesn't need the results pronto.

X, WCG sends to anyone who is actively crunching a project. I don't believe they don't prioritize machines to be sent to.

---

And, in all fairness, I should say that Silent Observer may not have realized some of the ramifications of what he proposed. And we should not belittle him for posting a perfectly honest and politely proposed idea.

Some such ideas and proposals do bear fruit at times.

So I hope he was not offended by my offhand dismissal of it in my earlier post.

Sorry, and please do not remain Silent.

As it has been a while since I crunched the WU's actively, and have done so off and on for years now (long before even 2005), I have missed out on a lot it would seem. Yes, I was unaware of the ramifications of my suggestion, which includes cheating, and had I known, I would not even have thought twice to mention it here. I am not dumb by any means, but I seem to have failed to think this one all the way through, before making the suggestion (I have been working 90 hour weeks, so fatigue played a good part in that). I am sorry if I offended anyone, and I do not want anyone here to think badly of me. I have been a member for many years, and never had a problem before, and do not want to start now. I thank all of you for the input, and letting me know why what I suggested, was not a good idea, as I too now see, and agree with your points of views. Lesson learned. Till the next time gentlemen.

---

http://www.goodsearch.com/nonprofit/university-of-california-setihome.aspx

When I signed up in 1999 the original point of seti@home was to crunch numbers making use of spare CPU cycles. Those that would otherwise go to waste. Back then, running a screen saver was not necessarily an easy task for a CPU. Using those CPU cycles for something more purposeful, like the SETI program made a lot of sense, and that provided a negative carbon footprint because it was "saving" CPU cycles instead of wasting them watching the windows logo fly around.

Fast forward into the future. Teams. Competition. Wingmen. CPU farms. Individuals spending thousands of dollars on hardware and energy for a project that is attempting to find an answer to a question that our current technology may not be able to answer. How many millions of kilowatts of power, how many barrels of oil have been spent on this project because it has spiraled far beyond the "spare" CPU cycles it was originally designed to do?

Obviously, for some people, the spare cpu cycle model gave way to brute force distributed computing. But as long as there are those of us only willing to donate our spare CPU cycles, you'll have to occassionally deal with the fact that we may "slow down" your credit.

---

When I signed up in 1999 the original point of seti@home was to crunch numbers making use of spare CPU cycles. Those that would otherwise go to waste. Back then, running a screen saver was not necessarily an easy task for a CPU. Using those CPU cycles for something more purposeful, like the SETI program made a lot of sense, and that provided a negative carbon footprint because it was "saving" CPU cycles instead of wasting them watching the windows logo fly around.

Fast forward into the future. Teams. Competition. Wingmen. CPU farms. Individuals spending thousands of dollars on hardware and energy for a project that is attempting to find an answer to a question that our current technology may not be able to answer. How many millions of kilowatts of power, how many barrels of oil have been spent on this project because it has spiraled far beyond the "spare" CPU cycles it was originally designed to do?

Obviously, for some people, the spare cpu cycle model gave way to brute force distributed computing. But as long as there are those of us only willing to donate our spare CPU cycles, you'll have to occassionally deal with the fact that we may "slow down" your credit.

Above all.....
Everybody must still observe that this is still a VOLUNTARY project.
Whether your computer cycles are 'spare' or 'manufactured', everybody contributes at the level they are willing or able to do so.
None is above the other, and that includes me.

Although I have been around a bit longer than some, and have crunched more than many, that does not make my opinion greater that thou.
Although I may think so on the random moment...LOL.

We are all in this together, and any one of us may one day find that WOW signal.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

I agree but I have a suggestion to ease off a little bit for some crunchers who are RAC maniac.

Repair tasks should have a shorter deadline and only send to fast and reliable hosts - just like at WCG. But then again server load will rise up.

After all, this project doesn't need the results pronto.

X, WCG sends to anyone who is actively crunching a project. I don't believe they don't prioritize machines to be sent to.

I was referring to the repair task - WCG has shorter deadline, only send to fast returner and no errors/invalids for certain time.

---

How many millions of kilowatts of power, how many barrels of oil have been spent on this project because it has spiraled far beyond the "spare" CPU cycles it was originally designed to do?

Probably about 1% of what it was costing NASA to do ONE shuttle launch :-|

It's still a Shoestring project, but the potential results are incredible. Good or Bad I don't know, but if ET is out there, it's better to know, and you will never know if you don't look.

A bit like Silent would never have known if his idea was good or bad unless he had asked. He asked, it got discussed, back to the drawing board...

Ian

What exactly am I getting Credit For?

hehehe

I am Null and Void and a Darwin Barnacle.

Credits = Ego polish

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

And just to throw my 2 cents in. My old P4 with its 3 day cache, More than likely turns work around faster then some of those liquid cooled barn burners with a 10 day cache. And I have had to wait for some of those guys to get a unit validated. Im with Sten and most of the others, Its money in the bank.

---

[/quote]

Old James

I can think of four basic reasons for long turnaround times.

1. Very slow computer. Those are only a tiny fraction of the active computers.

2. Computers which are not on continuously and only crunch when the user isn't actively using them.

3. Interactions between projects. For those computers running multiple projects with resource shares approximately equal, BOINC's logic will get the work done so it can be reported before the deadline if possible. Other than that it's basically FIFO, and tasks from another project with long run times can delay starting S@h work significantly.

4. Large cache settings, but obviously only when the cache is fairly full.

Some computers might actually be affected by more than one of those reasons, of course. The combination of large cache settings and multiple projects can lead to some work not getting done within deadline, neither the BOINC core client nor the server code estimations of how long work will take are very accurate. Also, a tiny work fetch request always gets one task (if available).

                                                                  Joe