Seems to me then that you need to make a decision as to the usefulness of the K6-2 class computers to meet your goals in the projects assigned to it. It's a user decision NOT a Boinc project decision.

Precisely. Can you point out to me where I said it was a project issue? Though, there is a decision to be made by the project for those owners of slower machines that want to contribute to the science.

Do they want those users to walk away? Or do they want their computer power too? I completely understand if they would rather those users walk away, and I would not have negative judgement against SETI if they said so.

I just wanted to make them understand the downside to this new 'feature'.

It's only a downside when they're sending three, and requiring two.

It has been stated that at some point in the (not too distant) future, they'll send two and require two.

This is a transient problem.

---

Seems to me then that you need to make a decision as to the usefulness of the K6-2 class computers to meet your goals in the projects assigned to it. It's a user decision NOT a Boinc project decision.

Precisely. Can you point out to me where I said it was a project issue? Though, there is a decision to be made by the project for those owners of slower machines that want to contribute to the science.

Do they want those users to walk away? Or do they want their computer power too? I completely understand if they would rather those users walk away, and I would not have negative judgement against SETI if they said so.

I just wanted to make them understand the downside to this new 'feature'.

---

Please read the entire thread. My AMD K6-2 500MHz will only download a single WU to fill a 2.75 day cache. There is no "unneeded" WUs to abort.

Since it takes 110 hours to finish a WU, and I find the average in every case so far that other results are returned within 24 hours, my slower computer always returns last in the quorum. The last computer to return usually just does this for credits. The first two are for the science.

Usually, it is this third WU that gets aborted, but since my K6-II only downloads a single WU and takes forever to finish it, the WU does not get aborted. My K6-II is forever relegated to working for credits instead of useful science.

Does that help make it any clearer?

To elaborate on that in the context of a newer 'big gun' battleship, lets consider the case where it would be attached to say 10 projects with equal RS for them. Your 'rocket' is now roughly 10 times 'slower' than it's measured Credit Rate would indicate due to timesharing. Now start letting the results 'ripen' for a while in the cache by running a 5 day CI or Work Override setting.

If you run 5.10 you're going to see your 221's balloon a bunch, and if running an earlier CC, your trailer percentage is going to spike. ;-)

Alinator

Seems to me then that you need to make a decision as to the usefulness of the K6-2 class computers to meet your goals in the projects assigned to it. It's a user decision NOT a Boinc or Seti project decision.

---

Boinc....Boinc....Boinc....Boinc....

Please read the entire thread. My AMD K6-2 500MHz will only download a single WU to fill a 2.75 day cache. There is no "unneeded" WUs to abort.

Since it takes 110 hours to finish a WU, and I find the average in every case so far that other results are returned within 24 hours, my slower computer always returns last in the quorum. The last computer to return usually just does this for credits. The first two are for the science.

Usually, it is this third WU that gets aborted, but since my K6-II only downloads a single WU and takes forever to finish it, the WU does not get aborted. My K6-II is forever relegated to working for credits instead of useful science.

Does that help make it any clearer?

To elaborate on that in the context of a newer 'big gun' battleship, lets consider the case where it would be attached to say 10 projects with equal RS for them. Your 'rocket' is now roughly 10 times 'slower' than it's measured Credit Rate would indicate due to timesharing. Now start letting the results 'ripen' for a while in the cache by running a 5 day CI or Work Override setting.

If you run 5.10 you're going to see your 221's balloon a bunch, and if running an earlier CC, your trailer percentage is going to spike. ;-)

Alinator

I know we cannot please everyone, but I *think* what OzzFan is asking is:
how can we make OLDER and SLOWER CPUs still do useful science. Hopefully, the vast majority of participants using older machines (and continuing to return WUs) are not terribly upset when granting credit is delayed.

Consistently returning WUs after quorum has already been reached is NOT useful.

YES!!!! I'm not even asking anyone to appease me since I have faster machines. All I'm making is an observation. What if someone else only owns an old, slower machine wants to contribute to SETI for the science? Not everyone, everywhere can afford to upgrade to faster/better offerings. Some get their PCs donated to them.

If SETI wants to say that they aren't needed, who am I to argue? But if SETI wants their help too, then I just wanted to bring it to their attention so that they may act on it if they wish.

That is all I'm saying.

Ned Ludd said it so well <snip>: "Remember that SETI is an experiment to search for ET. BOINC is an experiment to learn about (and develop) volunteer computing. We're participating in both."

I couldn't agree more.

---

We've both been around since 1999.
Since I don't have speakers on my PCs (& disable the internal speaker), I couldn't "hear" the children screaming. :) :)

I know we cannot please everyone, but I *think* what OzzFan is asking is:
how can we make OLDER and SLOWER CPUs still do useful science. Hopefully, the vast majority of participants using older machines (and continuing to return WUs) are not terribly upset when granting credit is delayed.

Consistently returning WUs after quorum has already been reached is NOT useful.

I always kindof chuckle at folks who are running with LARGE caches of WUs, and then complain about delays in getting credit and lots of other issues. Since most machines have always on internet access, I pretty much run with the defaults so the machines FINISH a WU before they request more work. This was a problem during SETI@Home, but now with BOINC I just attach to multiple projects. If one project is down, the machine will work on other projects...NO BIG DEAL!


Ned Ludd said it so well I may add a link to this post in my signature!! : "Remember that SETI is an experiment to search for ET. BOINC is an experiment to learn about (and develop) volunteer computing. We're participating in both."

Well there is an easy way; stop sending trailers by default.

That being said, the problem with old hosts isn't that there is a delay in getting credit granted, it's that the are wasting money and energy by running the work in the first place, since it doesn't contribute to anything to the science more times than not. In fact, it is very rare for my old timers to even have a result pending. Typically, if they even make the quorum they will be the one which completes it and thus get their credit granted virtually instantly.

The bottom line is sending trailers by default defeats the fault tolerant nature of BOINC, and until 221 functionality came along guaranteed that everyone would end up wasting at least some time running trailers, by definition. The only way to minimize it was to set BOINC up so that you never had more than one result per CPU per project, and then it's just a race to be one of the first 2 back. If you happen to have an OC'ed, optimized 5365, then you're in pretty good shape, if not then you're going to lose sometimes. ;-)

Alinator

I don't understand the logic which say's that the older and slower computers are not doing useful work. Using the current Boinc 5.10.13 work that is not needed will be aborted.

Please read the entire thread. My AMD K6-2 500MHz will only download a single WU to fill a 2.75 day cache. There is no "unneeded" WUs to abort.

Since it takes 110 hours to finish a WU, and I find the average in every case so far that other results are returned within 24 hours, my slower computer always returns last in the quorum. The last computer to return usually just does this for credits. The first two are for the science.

Usually, it is this third WU that gets aborted, but since my K6-II only downloads a single WU and takes forever to finish it, the WU does not get aborted. My K6-II is forever relegated to working for credits instead of useful science.

Does that help make it any clearer?

---

I'd *strongly* suggest that additional (above quorum needs) WUs *not* be sent till after reporting deadline.

This seems to be a 'no brainer'.
No where in this thread have I read a REASONABLE rational for sending more than the quorum needs.

You obviously weren't here in the days when the children were screaming like stuck pigs because it took more than an hour after they returned their result before they got their credit.

We've both been around since 1999.
Since I don't have speakers on my PCs (& disable the internal speaker), I couldn't "hear" the children screaming. :) :)

I know we cannot please everyone, but I *think* what OzzFan is asking is:
how can we make OLDER and SLOWER CPUs still do useful science. Hopefully, the vast majority of participants using older machines (and continuing to return WUs) are not terribly upset when granting credit is delayed.

Consistently returning WUs after quorum has already been reached is NOT useful.

I always kindof chuckle at folks who are running with LARGE caches of WUs, and then complain about delays in getting credit and lots of other issues. Since most machines have always on internet access, I pretty much run with the defaults so the machines FINISH a WU before they request more work. This was a problem during SETI@Home, but now with BOINC I just attach to multiple projects. If one project is down, the machine will work on other projects...NO BIG DEAL!


Ned Ludd said it so well I may add a link to this post in my signature!! : "Remember that SETI is an experiment to search for ET. BOINC is an experiment to learn about (and develop) volunteer computing. We're participating in both."

If the project changes the initial WU issue to 2 instead of 3, then all or most of the work returned by 'the little crunchers' once again becomes valid science.
I thing Matt or Eric have indicated this is what their intention is once MB is online and running.

---

"Learn from yesterday. Live for today. Hope for tomorrow." Albert Einstein
"With cats." kittyman

When one of my results finished I expected it to be reported a few minutes later but it did not.

Using 5.10.13, my K6-2 seemed to report it within a short amount of time, but I think that's more related to the fact that a single WU filled it's entire 2.75 day cache so it had to report immediately to get a new WU.

---

I don't understand the logic which say's that the older and slower computers are not doing useful work. Using the current Boinc 5.10.13 work that is not needed will be aborted.

Even a slow computer carrying a 10 day work cache all work that is not needed will be aborted. There are always work units trickling to the top of the cache that need to be worked. Even with a 10 day cache. This insures that at the time the work unit is started to crunch it has NOT been returned by the other client computers and has NOT reached quorum. So what is the problem here? So there is a small chance the other client computers will complete it first and then still be a trailer. There is that small chance in all the work done, even by fast computers. The slower computers are still useful and needed here.

---

Boinc....Boinc....Boinc....Boinc....

I'd *strongly* suggest that additional (above quorum needs) WUs *not* be sent till after reporting deadline.

This seems to be a 'no brainer'.
No where in this thread have I read a REASONABLE rational for sending more than the quorum needs.

You obviously weren't here in the days when the children were screaming like stuck pigs because it took more than an hour after they returned their result before they got their credit.

We've both been around since 1999.
Since I don't have speakers on my PCs (& disable the internal speaker), I couldn't "hear" the children screaming. :) :)

I know we cannot please everyone, but I *think* what OzzFan is asking is:
how can we make OLDER and SLOWER CPUs still do useful science. Hopefully, the vast majority of participants using older machines (and continuing to return WUs) are not terribly upset when granting credit is delayed.

Consistently returning WUs after quorum has already been reached is NOT useful.

I always kindof chuckle at folks who are running with LARGE caches of WUs, and then complain about delays in getting credit and lots of other issues. Since most machines have always on internet access, I pretty much run with the defaults so the machines FINISH a WU before they request more work. This was a problem during SETI@Home, but now with BOINC I just attach to multiple projects. If one project is down, the machine will work on other projects...NO BIG DEAL!


Ned Ludd said it so well I may add a link to this post in my signature!! : "Remember that SETI is an experiment to search for ET. BOINC is an experiment to learn about (and develop) volunteer computing. We're participating in both."

---

SETI@home since 1999
"Set it, and Forget it!"

I Agree. I don't want to waste electricy and space with an old slow computer that is doing little or no science. My solution is to upgrade the old slow computers. A quad systems uses about the same amount of power as an old PII. (I know a little more, but not significally so.) So dump the PII and get a quad. My slowest computer was a P4, 2 Ghz. I repaced the MB and processor with a Q6600. Kept the memory, HD, case, Power Supply, etc. So for about $325 I have a much more productive system.

I take it you haven't read this entire thread? 1) It's not a PII. It's an AMD K6-2 500MHz. 2) It's not my main system, and therefore not in need of upgrading. 3) It's part of my computer museum that I figured I should put to use as long as I own them, to do useful science. 4) With skyrocketing costs here in the US, I try to keep things useful. If I cannot justify something, I have to get rid of it (in this case, turning it off, as I'm not going to get rid of my museum).

---

@ OzzFan

I have argued against your claim that slow host are not very usefull anymore.
But I just had a nasty surprise.

As a experiment I installed BOINC version 5.10.17 on one of my hosts.

This host has a CI of 0.001, a cache of 10 days and is running in EDF at the moment.

When one of my results finished I expected it to be reported a few minutes later but it did not.

So I had a look at the changelog of the BOINC developers and found that they no longer take the CI as lead for returning results. It is possible that it will take up to one day before a result is returned. I expect that in most situations results will be returned before that when there is a request for new work.

This delay in reporting however kind of defeats the "Aborted by project" feature because it works most efficient when the server is contacted often and that will no longer happen when a host is in EDF. The only way to avoid EDF is having a cache smaller than the shortest WU, something smaller then 4 days.

And that means older host taking more then that number of days are out.

PS: What I don't understand why developers have introduced the "Aborted by project" feature plus the additional cache option and then make another rule that makes it useless.

Do you have a global_prefs_override.xml file in your BOINC folder, and if so did you set the CI on the 'my account' page or using advanced/preferences?

Setting CI in advanced/prefernces works for me:
06/08/2007 14:40:08|SETI@home|Computation for task 02mr00aa.12220.31025.761084.3.109_2 finished
06/08/2007 14:40:08|SETI@home|Starting 29mr00ab.25614.13826.848592.3.235_1
06/08/2007 14:40:08|SETI@home|Starting task 29mr00ab.25614.13826.848592.3.235_1 using setiathome_enhanced version 517
06/08/2007 14:40:10|SETI@home|[file_xfer] Started upload of file 02mr00aa.12220.31025.761084.3.109_2_0
06/08/2007 14:40:15|SETI@home|[file_xfer] Finished upload of file 02mr00aa.12220.31025.761084.3.109_2_0 resultid=585473121
06/08/2007 14:40:15|SETI@home|[file_xfer] Throughput 8588 bytes/sec
06/08/2007 14:41:44|SETI@home|Sending scheduler request: To report completed tasks
06/08/2007 14:41:44|SETI@home|Reporting 1 tasks
06/08/2007 14:41:49|SETI@home|Scheduler RPC succeeded [server version 511]
06/08/2007 14:41:49|SETI@home|Deferring communication for 11 sec

times are UTC +1, as you can see report is 00:01:29 after unit uploads.

Andy

You are not using BOINC 5.10.14 or higher where this change in CI handeling is made.

True, sorry. In that case I have to agree with you. And therefore probably wont upgrade soon, until I find a way of reporting soon after completion. I was caught around a maintenance outage. Units uploaded just before outage, but down/upload server didn't work correctly after outage but reporting did. Validator said files not found for four or five units.

Andy

@ OzzFan

I have argued against your claim that slow host are not very usefull anymore.
But I just had a nasty surprise.

As a experiment I installed BOINC version 5.10.17 on one of my hosts.

This host has a CI of 0.001, a cache of 10 days and is running in EDF at the moment.

When one of my results finished I expected it to be reported a few minutes later but it did not.

So I had a look at the changelog of the BOINC developers and found that they no longer take the CI as lead for returning results. It is possible that it will take up to one day before a result is returned. I expect that in most situations results will be returned before that when there is a request for new work.

This delay in reporting however kind of defeats the "Aborted by project" feature because it works most efficient when the server is contacted often and that will no longer happen when a host is in EDF. The only way to avoid EDF is having a cache smaller than the shortest WU, something smaller then 4 days.

And that means older host taking more then that number of days are out.

PS: What I don't understand why developers have introduced the "Aborted by project" feature plus the additional cache option and then make another rule that makes it useless.

Do you have a global_prefs_override.xml file in your BOINC folder, and if so did you set the CI on the 'my account' page or using advanced/preferences?

Setting CI in advanced/prefernces works for me:
06/08/2007 14:40:08|SETI@home|Computation for task 02mr00aa.12220.31025.761084.3.109_2 finished
06/08/2007 14:40:08|SETI@home|Starting 29mr00ab.25614.13826.848592.3.235_1
06/08/2007 14:40:08|SETI@home|Starting task 29mr00ab.25614.13826.848592.3.235_1 using setiathome_enhanced version 517
06/08/2007 14:40:10|SETI@home|[file_xfer] Started upload of file 02mr00aa.12220.31025.761084.3.109_2_0
06/08/2007 14:40:15|SETI@home|[file_xfer] Finished upload of file 02mr00aa.12220.31025.761084.3.109_2_0 resultid=585473121
06/08/2007 14:40:15|SETI@home|[file_xfer] Throughput 8588 bytes/sec
06/08/2007 14:41:44|SETI@home|Sending scheduler request: To report completed tasks
06/08/2007 14:41:44|SETI@home|Reporting 1 tasks
06/08/2007 14:41:49|SETI@home|Scheduler RPC succeeded [server version 511]
06/08/2007 14:41:49|SETI@home|Deferring communication for 11 sec

times are UTC +1, as you can see report is 00:01:29 after unit uploads.

Andy

You are not using BOINC 5.10.14 or higher where this change in CI handeling is made.

---

@ OzzFan

I have argued against your claim that slow host are not very usefull anymore.
But I just had a nasty surprise.

As a experiment I installed BOINC version 5.10.17 on one of my hosts.

This host has a CI of 0.001, a cache of 10 days and is running in EDF at the moment.

When one of my results finished I expected it to be reported a few minutes later but it did not.

So I had a look at the changelog of the BOINC developers and found that they no longer take the CI as lead for returning results. It is possible that it will take up to one day before a result is returned. I expect that in most situations results will be returned before that when there is a request for new work.

This delay in reporting however kind of defeats the "Aborted by project" feature because it works most efficient when the server is contacted often and that will no longer happen when a host is in EDF. The only way to avoid EDF is having a cache smaller than the shortest WU, something smaller then 4 days.

And that means older host taking more then that number of days are out.

PS: What I don't understand why developers have introduced the "Aborted by project" feature plus the additional cache option and then make another rule that makes it useless.

Do you have a global_prefs_override.xml file in your BOINC folder, and if so did you set the CI on the 'my account' page or using advanced/preferences?

Setting CI in advanced/prefernces works for me:
06/08/2007 14:40:08|SETI@home|Computation for task 02mr00aa.12220.31025.761084.3.109_2 finished
06/08/2007 14:40:08|SETI@home|Starting 29mr00ab.25614.13826.848592.3.235_1
06/08/2007 14:40:08|SETI@home|Starting task 29mr00ab.25614.13826.848592.3.235_1 using setiathome_enhanced version 517
06/08/2007 14:40:10|SETI@home|[file_xfer] Started upload of file 02mr00aa.12220.31025.761084.3.109_2_0
06/08/2007 14:40:15|SETI@home|[file_xfer] Finished upload of file 02mr00aa.12220.31025.761084.3.109_2_0 resultid=585473121
06/08/2007 14:40:15|SETI@home|[file_xfer] Throughput 8588 bytes/sec
06/08/2007 14:41:44|SETI@home|Sending scheduler request: To report completed tasks
06/08/2007 14:41:44|SETI@home|Reporting 1 tasks
06/08/2007 14:41:49|SETI@home|Scheduler RPC succeeded [server version 511]
06/08/2007 14:41:49|SETI@home|Deferring communication for 11 sec

times are UTC +1, as you can see report is 00:01:29 after unit uploads.

Andy

@ OzzFan

I have argued against your claim that slow host are not very usefull anymore.
But I just had a nasty surprise.

As a experiment I installed BOINC version 5.10.17 on one of my hosts.

This host has a CI of 0.001, a cache of 10 days and is running in EDF at the moment.

When one of my results finished I expected it to be reported a few minutes later but it did not.

So I had a look at the changelog of the BOINC developers and found that they no longer take the CI as lead for returning results. It is possible that it will take up to one day before a result is returned. I expect that in most situations results will be returned before that when there is a request for new work.

This delay in reporting however kind of defeats the "Aborted by project" feature because it works most efficient when the server is contacted often and that will no longer happen when a host is in EDF. The only way to avoid EDF is having a cache smaller than the shortest WU, something smaller then 4 days.

And that means older host taking more then that number of days are out.

PS: What I don't understand why developers have introduced the "Aborted by project" feature plus the additional cache option and then make another rule that makes it useless.

---

But if slower computers aren't doing as much valid science, then there isn't a point to running them, is there? The answer to that question for me is 'no'.

I Agree. I don't want to waste electricy and space with an old slow computer that is doing little or no science. My solution is to upgrade the old slow computers. A quad systems uses about the same amount of power as an old PII. (I know a little more, but not significally so.) So dump the PII and get a quad. My slowest computer was a P4, 2 Ghz. I repaced the MB and processor with a Q6600. Kept the memory, HD, case, Power Supply, etc. So for about $325 I have a much more productive system.

---

So less than 4.5% of those units over two days old have not been granted credit for this computer.

It's amazing the amount of noise that can generated over small & insignificant things though.

Well, that's the difference. What may seem small and insignificant to you may not be to me or others. Everyone has a right to voice their concerns.


However, I didn't mean for this topic to get so defensive. I just made a simple observation, even if it was already apparent to everyone else, and all I was looking for was confirmation.

Anyone who reads my posts, especially those posts of mine defending SETI during server troubles should know that I don't like to blow things out of proportion and I usually have a level head about most issues.

I am not arguing against the new "Aborted by project" feature, I was simply hoping to shed some more light on one of the downsides to such a feature. Actually, I am a fan of the new feature and think more valid science is a good thing. But if slower computers aren't doing as much valid science, then there isn't a point to running them, is there? The answer to that question for me is 'no'. To others in this post... well, apparently they have a different view and I can respect that.

---

So less than 4.5% of those units over two days old have not been granted credit for this computer.

So, based upon these numbers, most workunits are getting returned in a very timely manor, thus making older, slower computers obsolete as far as actual science is concerned.

I'm glad I wasn't the only one that noticed and confirmed my observation.

---

So less than 4.5% of those units over two days old have not been granted credit for this computer.

It's amazing the amount of noise that can generated over small & insignificant things though.

---

Grant
Darwin NT