I Posted this in Number Crunching, but fear it won't be read there, so I'm copy and pasting here.

1) I know regular rosetta doesn't utilitize redundancy

2) I know I've seen many posts from users in the regular message boards listing troubled WUs.

3) I know they are low on work in Ralph

4) I don't know how work is generated in Ralph

Given these things, I have an idea. Why not utilize the redundancy, the suspected bad WUs on message board, and the device which doesn't send a copy of the same WU to the same user, and generate say 6 or more copies of each suspect WU and send them out.
This would make more work, let others see if the reported problem exists, and if so on what systems. etc, etc, etc.

tony

---

Formerly
mmciastro. Name and avatar changed for a change

The New Online Helpsytem help is just a call away.

I'm starting to see reported wus in Ralph also, they to could be recycled out to new users as well.

Hi,

Please do not consider my suggestion to be a change to the guidelines unless and until David adopts it in the main GUIDELINES thread.

I am wondering why a low resource share? A high resource share would mean that when test WU are available, you get feedback fast.

If you don't want one machine to crunch lots of wu, my suggestion would be to set a fairly low quota. That would mean that no machine could crunch many test units per day, but that turnround would also be quick.

This would also prevent people from building up large caches of RALPH wu, even if they normally hold long caches for other projects.

Finally it would mean a better spread of test WU between slow and fast machines. For bug-catching that would seem to be a better balance.

River~~

edit - add:

PS David, I'd suggest also you 'sticky' your guidelines thread too ;-)

---

Sounds good to me. I will lower the quota. Since test work units will come and go fairly infrequently, a small resource share should not really hurt us. Let's see how it goes. edit: I took the resource share recommendation off the guidelines page.

---

Sounds good to me. I will lower the quota. Since test work units will come and go fairly infrequently, a small resource share should not really hurt us. Let's see how it goes. edit: I took the resource share recommendation off the guidelines page.

Actually I am not so sure River has this figured right. He is correct on the feedback rate, but, if someone with a high resource share is pounding the server, and they have their contact interval set high (big queue). When they get WUs they will get a lot of them. That will not leave many for the rest of the users. This will have the effect of reducing the number of different systems that can get WUs. Meanwhile the client is building a project debt faster with the higher share value, so when the work come in the system will likely shift to Ralph for a while exclusively. This will upset a lot of the multi project users.

I would think a better approach would be to limit the actual number of WUs each system can take form the available pool. Instead of relying on the normal request process, perhaps the server should only recognize that a request has been made (forget the number of seconds of work requested) and give out only a specified number of WUs, say 3-6. I got 6 when I first signed up, and you can keep them cooking a long time with the new time setting, or let them go fast if you need to get them reported.

But since you know the number of systems in the pool of users, you can size the work generation step to provide a certain number of WUs for all of those systems. I really think the only way to make certain a good sample of system types will get test work is some form of direct rationing at the start of a test run.

---

I think Gravywavy (oops, sorry, River) has it right, setting the resource share to higher means it'll keep a debt that needs filling. Also, Reducing the quota per day will mean you can only get say 10/day. So, the minute work is available, the host will get ONLY 10 WUs for that day. Setting the deadline short will ensure that those 10 get crunched first. Then days will pass when other projects will run because Ralph has no work, but when work is available, it's downloaded with priority, and crunched with priority.

As to the pounding of the server, a low resource share and no work available will result in almost the same pounding. The built in expotential communication back offs will help lessen the load. The bandwidth for an RPC call is much smaller than that of an actual exchange of data (read work)

tony

I think Gravywavy (oops, sorry, River) has it right, setting the resource share to higher means it'll keep a debt that needs filling. Also, Reducing the quota per day will mean you can only get say 10/day. So, the minute work is available, the host will get ONLY 10 WUs for that day. Setting the deadline short will ensure that those 10 get crunched first. Then days will pass when other projects will run because Ralph has no work, but when work is available, it's downloaded with priority, and crunched with priority.

As to the pounding of the server, a low resource share and no work available will result in almost the same pounding. The built in expotential communication back offs will help lessen the load. The bandwidth for an RPC call is much smaller than that of an actual exchange of data (read work)

tony

What makes any of you assume that the bulk of the users are going to set their systems in the way that you specify? I think we have ample proof that most in fact will ignore almost any instructions that are available in the reading material in these forums for this project, and set their system as if this was a production project. Very few people have taken the time to recognize the nature of testing, and set their systems for that purpose.

The fact is there will be a lot of people who will grab as many test WUs as they can (for whatever reason), and this will prevent others from having any. The effect of this is to reduce the variety of systems that are running the test WUs. The only way to stop that is to turn off credit granting, or ration the Wus for better distribution.

The best solution for this it to not rely on the BOINC requesting system, beyond recognizing that a request for work has been made, and deliver a specific number of WUs to each requesting system over a specified period of time. Now it is true that some will not be happy because they will have less than they want, and some will not be happy because they may have a few more than they want. But hey, Alpha projects are not for everyone.

---

Moderator9
RALPH@home FAQs
RALPH@home Guidelines
Moderator Contact

What makes any of you assume that the bulk of the users are going to set their systems in the way that you specify? ...

The best solution for this it to not rely on the BOINC requesting system, beyond recognizing that a request for work has been made,...

I was not assuming that. Your point actually strengthens mine: the quota is set by the project not by the user. By setting a low quota this limits the number of wu that can be downloaded in any one day. This is almost as good as limiting the number over a period of time, with the added advantage of not needing any new coding, just a change to the max quota size by the project admins.

And, as you suggest, this is independent of what a user sets (unless a user chooses to download even less than that, of course...)


River~~


PS - m9 I worked out why I could not find my posting before - there is a BOINC bug so that when a mod moves a posting, the 'latest post' times do not get updated. I hadn't looked in this thread as it looked like nothing had been added for three days... R~~

---

...
Actually I am not so sure River has this figured right. He is correct on the feedback rate, but, if someone with a high resource share is pounding the server, and they have their contact interval set high (big queue). When they get WUs they will get a lot of them. ...

er no. On my scheme (small quota set by project, large resource share set by user) when a user gets work s/he will get the max number of WU as set by the quota.

Users who do not set a large resource share will also get the same number, as set by the quota, but will simply take longer to return them - annoyng to David & colleagues but this will not affect how many other users get.

edit: oh, Ive just read that David will not find this annoying...

Users who set miniscule resource shares will get fewer than the quota.

Users who set cache size of n days (n>1) may find their client only looks for work once every n days, so they'd only get a quota every n days.

Overall, as m9 says, we cannot assume anyone will do as they are asked, but this scheme (a) makes it most advantageous to the user to do so, and (b) minimises the bad news for the rest of us if they don't.

River~~

---

By setting a low quota this limits the number of wu that can be downloaded in any one day
=========

Thats how the PrimeGrid Project allots the WU's, although once you crunch for a few days the allotment is quite generous. But the Quota for RALPH could be set at a certain amount & left there instead of rising like it does at the PrimeGrid Project.

But then I suppose you would have to brace yourself for the onslaught of whining that would come from doing that by people wanting more WU's.

I can live with whatever the Project wants to dole out, thats what the other Projects are for I figure, to take up any slack I might encounter here or at another Project.

What makes any of you assume that the bulk of the users are going to set their systems in the way that you specify? ...

The best solution for this it to not rely on the BOINC requesting system, beyond recognizing that a request for work has been made,...

I was not assuming that. Your point actually strengthens mine: the quota is set by the project not by the user. By setting a low quota this limits the number of wu that can be downloaded in any one day. This is almost as good as limiting the number over a period of time, with the added advantage of not needing any new coding, just a change to the max quota size by the project admins.

And, as you suggest, this is independent of what a user sets (unless a user chooses to download even less than that, of course...)


River~~


PS - m9 I worked out why I could not find my posting before - there is a BOINC bug so that when a mod moves a posting, the 'latest post' times do not get updated. I hadn't looked in this thread as it looked like nothing had been added for three days... R~~

Ok, I misunderstood that you were talking about changing the options in the prefs page to prevent large queues. Now I understand where you are coming from.

As to the forum bug you are correct, I have reported it to the BOINC Devs and they say they will try to fix in in the next baseline. It is really annoying as a Mod. Probably madding as a user too.

---

Moderator9
RALPH@home FAQs
RALPH@home Guidelines
Moderator Contact

I think we have ample proof that most in fact will ignore almost any instructions that are available

thats fine for a beta test where you want lotsa users that don't mind the odd crash, but alpha projects require user interaction and feedback, ya it was a few days after i first got work that i read these boards throughly.
I appreciate the opportunity for "shared learning" afforded me by my being allowed into the alpha test pool and am quite happy to have a Obligation to follow directions.

---

Looks like they've implemented the idea River put forward. I see all my puters now have a max quota of 12 wus/day.

Hmmm, (applying math functions)

1 hour cpu pref = 1/2 day full time running
2 hour =full day run
4 hour + = more than a days worth.

Looks like they've implemented the idea River put forward.

again

(he says modestly)

;-)

As to the forum bug ... I have reported it to the BOINC Devs ...

- was going to do that when I got round to it (honest) but thanks for saving me the effort :)

---

As to the forum bug ... I have reported it to the BOINC Devs ...

- was going to do that when I got round to it (honest) but thanks for saving me the effort :)

Ok so the new distribution of Wus has a small problem. When the WUs error or are cancelled by the user, the Quota drops, and they are having trouble getting any more WUs. For testing this the negative impact of reducing the results flow fron the machines that are erroring. These of course are the very WUs that you are looking for. WHile the quota never drops to zero (so Im told) it can drop low enough that people can't get any WUs to run on the machines producing the errors for long periods of time.

---

Moderator9
RALPH@home FAQs
RALPH@home Guidelines
Moderator Contact

I agree with mmciastro, you may as well stick in redundancy. I can't see any down side to this. Yes we all probably do Rosetta@Home as well, so the redundancy will slow us down, but we are a very small sample of Rosetta@Home. I doubt very much if you will see a slump in Rosetta@Home's computing power :)

---

When the WUs error or are cancelled by the user, the Quota drops, and they are having trouble getting any more WUs. For testing this the negative impact of reducing the results flow fron the machines that are erroring. These of course are the very WUs that you are looking for.

They ARE the WUs you are looking for, and from the hosts you want to study. So, the host showed a problem, let's study it and fix it in another Ralph test version. But if that problematic host is unable to get ANY WUs with the next test version, then you still have a problem with the test plan.

I've got some other comments about the sideeffects many of these approaches must be having on Ralph in another thread. Please have a look and see if you think I'm on track there.

---