Creating work for Ralph

Message boards : Feedback : Creating work for Ralph

To post messages, you must log in.

AuthorMessage
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 98 - Posted: 17 Feb 2006, 1:11:14 UTC

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.
ID: 98 · Report as offensive    Reply Quote
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 104 - Posted: 17 Feb 2006, 1:51:21 UTC

I'm starting to see reported wus in Ralph also, they to could be recycled out to new users as well.
ID: 104 · Report as offensive    Reply Quote
River~~

Send message
Joined: 20 Feb 06
Posts: 20
Credit: 503
RAC: 0
Message 380 - Posted: 20 Feb 2006, 18:39:33 UTC
Last modified: 20 Feb 2006, 18:41:21 UTC

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 ;-)
ID: 380 · Report as offensive    Reply Quote
Profile dekim
Volunteer moderator
Project administrator
Project developer
Project scientist

Send message
Joined: 20 Jan 06
Posts: 250
Credit: 543,579
RAC: 0
Message 409 - Posted: 21 Feb 2006, 4:00:14 UTC
Last modified: 21 Feb 2006, 4:09:04 UTC

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.
ID: 409 · Report as offensive    Reply Quote
Snake Doctor

Send message
Joined: 16 Feb 06
Posts: 37
Credit: 998,880
RAC: 0
Message 415 - Posted: 21 Feb 2006, 6:32:03 UTC - in response to Message 409.  

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.
ID: 415 · Report as offensive    Reply Quote
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 416 - Posted: 21 Feb 2006, 6:50:42 UTC
Last modified: 21 Feb 2006, 6:53:57 UTC

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
ID: 416 · Report as offensive    Reply Quote
Moderator9
Volunteer moderator

Send message
Joined: 16 Feb 06
Posts: 251
Credit: 0
RAC: 0
Message 423 - Posted: 21 Feb 2006, 16:04:52 UTC - in response to Message 416.  

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
ID: 423 · Report as offensive    Reply Quote
River~~

Send message
Joined: 20 Feb 06
Posts: 20
Credit: 503
RAC: 0
Message 424 - Posted: 21 Feb 2006, 16:26:22 UTC - in response to Message 423.  




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~~
ID: 424 · Report as offensive    Reply Quote
River~~

Send message
Joined: 20 Feb 06
Posts: 20
Credit: 503
RAC: 0
Message 426 - Posted: 21 Feb 2006, 16:33:10 UTC - in response to Message 415.  
Last modified: 21 Feb 2006, 16:49:18 UTC

...
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~~

ID: 426 · Report as offensive    Reply Quote
STE\/E

Send message
Joined: 16 Feb 06
Posts: 27
Credit: 2,226,442
RAC: 783
Message 427 - Posted: 21 Feb 2006, 16:39:27 UTC

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.
ID: 427 · Report as offensive    Reply Quote
Moderator9
Volunteer moderator

Send message
Joined: 16 Feb 06
Posts: 251
Credit: 0
RAC: 0
Message 443 - Posted: 22 Feb 2006, 1:20:08 UTC - in response to Message 424.  




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
ID: 443 · Report as offensive    Reply Quote
Profile Morgan the Gold

Send message
Joined: 15 Feb 06
Posts: 8
Credit: 187,911
RAC: 0
Message 464 - Posted: 22 Feb 2006, 5:54:14 UTC

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.

ID: 464 · Report as offensive    Reply Quote
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 527 - Posted: 23 Feb 2006, 11:52:20 UTC
Last modified: 23 Feb 2006, 11:54:46 UTC

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.
ID: 527 · Report as offensive    Reply Quote
River~~

Send message
Joined: 20 Feb 06
Posts: 20
Credit: 503
RAC: 0
Message 534 - Posted: 23 Feb 2006, 17:22:12 UTC - in response to Message 527.  

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


again

(he says modestly)

;-)
ID: 534 · Report as offensive    Reply Quote
River~~

Send message
Joined: 20 Feb 06
Posts: 20
Credit: 503
RAC: 0
Message 535 - Posted: 23 Feb 2006, 17:24:41 UTC - in response to Message 443.  



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 :)
ID: 535 · Report as offensive    Reply Quote
Moderator9
Volunteer moderator

Send message
Joined: 16 Feb 06
Posts: 251
Credit: 0
RAC: 0
Message 634 - Posted: 25 Feb 2006, 15:42:01 UTC - in response to Message 535.  
Last modified: 25 Feb 2006, 15:44:34 UTC



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
ID: 634 · Report as offensive    Reply Quote
hugothehermit

Send message
Joined: 17 Feb 06
Posts: 17
Credit: 2,170
RAC: 0
Message 697 - Posted: 27 Feb 2006, 7:33:36 UTC

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 :)


ID: 697 · Report as offensive    Reply Quote
Profile feet1st

Send message
Joined: 7 Mar 06
Posts: 313
Credit: 116,623
RAC: 0
Message 1373 - Posted: 26 Apr 2006, 10:43:19 UTC - in response to Message 634.  
Last modified: 26 Apr 2006, 10:43:46 UTC

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.

ID: 1373 · Report as offensive    Reply Quote

Message boards : Feedback : Creating work for Ralph



©2024 University of Washington
http://www.bakerlab.org