Message boards : Number crunching : I think we should restrict work units
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · 4 · 5 . . . 11 · Next

AuthorMessage
Gaspode the UnDressed

Send message
Joined: 1 Sep 04
Posts: 506
Credit: 118,619
RAC: 0
Message 13728 - Posted: 25 May 2006, 10:27:59 UTC - in response to Message 13724.  
Last modified: 25 May 2006, 10:28:56 UTC

It is important to MaxCache LHC becuase it takes only 18-30 hours for them to run out of work once they put it up (looks like they put up 80000-150000 WUs at a time).


What's important is getting the work done. As I write this, GreatInca, one of your computers still has eight results left to run, while my computers have been out of work for two or three days. Had you not filled your cache to excess the eight results could have been assigned to other computers and the work completed days ago. Spread this across thousands of users and the tail of unreturned results drags out for days.

Each study generally requires analysis of the previous study to determine appropriate parameters. If each study is completed more quickly the next one can be released sooner. The message, therefore is:

Keep your cache as small as possible.




Gaspode the UnDressed
http://www.littlevale.co.uk
ID: 13728 · Report as offensive     Reply Quote
Profile Keck_Komputers

Send message
Joined: 1 Sep 04
Posts: 275
Credit: 2,652,452
RAC: 0
Message 13729 - Posted: 25 May 2006, 11:09:26 UTC - in response to Message 13724.  

Since LHC runs out of work in 18 - 30 hours it is important to set your queue no higher than this, ie. 1.5 days at most. This project is about getting results back quickly not building up a stockpile of work. Having a high resource share will cause you to mostly do LHC work when it is available.
BOINC WIKI

BOINCing since 2002/12/8
ID: 13729 · Report as offensive     Reply Quote
Profile Steve Cressman
Avatar

Send message
Joined: 28 Sep 04
Posts: 47
Credit: 6,394
RAC: 0
Message 13734 - Posted: 25 May 2006, 14:00:49 UTC - in response to Message 13728.  

It is important to MaxCache LHC becuase it takes only 18-30 hours for them to run out of work once they put it up (looks like they put up 80000-150000 WUs at a time).


What's important is getting the work done. As I write this, GreatInca, one of your computers still has eight results left to run, while my computers have been out of work for two or three days. Had you not filled your cache to excess the eight results could have been assigned to other computers and the work completed days ago. Spread this across thousands of users and the tail of unreturned results drags out for days.

Each study generally requires analysis of the previous study to determine appropriate parameters. If each study is completed more quickly the next one can be released sooner. The message, therefore is:

Keep your cache as small as possible.

I just call it what it is, GREED. Greed causes people to grab as much as they can. Greedy people don't care about others or the project. The front page still says there is work in progress. This work could have all been completed by now if it was not for greed.

From the dictionary:

greed - excessive desire to acquire or possess more (especially more material wealth) than one needs or deserves

- reprehensible acquisitiveness; insatiable desire for wealth (personified as one of the deadly sins)

In this case it is not wealth they are after but credits that have NO VALUE
Keep your cache as small as possible.
98SE XP2500+ @ 2.1 GHz Boinc v5.8.8
ID: 13734 · Report as offensive     Reply Quote
Profile anarchic teapot
Avatar

Send message
Joined: 15 Feb 06
Posts: 67
Credit: 460,896
RAC: 0
Message 13735 - Posted: 25 May 2006, 14:56:02 UTC - in response to Message 13734.  


Keep your cache as small as possible.


Yes, well, there are always the idiots that think bigger is better.
Personally, I reckon they're compensating for something.


(you're right, Steve, they are greedy little antisocial pigs)

sQuonk
Plague of Mice
Intel Core i3-9100 CPU@3.60 GHz, but it's doing its bit just the same.
ID: 13735 · Report as offensive     Reply Quote
MRAO

Send message
Joined: 4 Mar 06
Posts: 3
Credit: 389,392
RAC: 0
Message 13736 - Posted: 25 May 2006, 16:28:38 UTC - in response to Message 13735.  


Keep your cache as small as possible.


Yes, well, there are always the idiots that think bigger is better.
Personally, I reckon they're compensating for something.


(you're right, Steve, they are greedy little antisocial pigs)

A case where a smaller "max units a day" figure might be useful? It would give more people a chance of making a useful contribution to the project.
ID: 13736 · Report as offensive     Reply Quote
Dronak
Avatar

Send message
Joined: 19 May 06
Posts: 20
Credit: 297,111
RAC: 0
Message 13742 - Posted: 25 May 2006, 21:45:30 UTC - in response to Message 13729.  

Having a high resource share will cause you to mostly do LHC work when it is available.


This is a bit of an aside to the original topic, but I hope people don't mind. I used to run only one project, so I'm trying to learn how to manage multiple projects effectively. If I give LHC a large resource share, it will get more CPU time. But will doing that cause LHC to eat up computer time even when there's no work available? I don't want projects with work to sit idle while LHC attempts to get non-existent work. Does resource share have an effect if you have no work to do? If not, increasing it now to prepare for next time should be fine and not change anything until LHC work units come in. I just want to check and make sure I understand how things work. Thanks for the help.
ID: 13742 · Report as offensive     Reply Quote
Bill Hepburn

Send message
Joined: 18 Sep 04
Posts: 10
Credit: 5,151,492
RAC: 33
Message 13744 - Posted: 25 May 2006, 22:50:08 UTC - in response to Message 13742.  



This is a bit of an aside to the original topic, but I hope people don't mind. I used to run only one project, so I'm trying to learn how to manage multiple projects effectively. If I give LHC a large resource share, it will get more CPU time. But will doing that cause LHC to eat up computer time even when there's no work available? I don't want projects with work to sit idle while LHC attempts to get non-existent work. Does resource share have an effect if you have no work to do? If not, increasing it now to prepare for next time should be fine and not change anything until LHC work units come in. I just want to check and make sure I understand how things work. Thanks for the help.


BOINC handles that situation pretty well, actually. When a project runs out of work, the scheduler effectively ignores it (it sets the "short term debt" to zero). When work becomes available, it starts paying attention again.

The BOINC Wiki has more information than you would ever want to know about the work scheduler.


ID: 13744 · Report as offensive     Reply Quote
Dronak
Avatar

Send message
Joined: 19 May 06
Posts: 20
Credit: 297,111
RAC: 0
Message 13746 - Posted: 26 May 2006, 0:51:46 UTC - in response to Message 13744.  

BOINC handles that situation pretty well, actually. When a project runs out of work, the scheduler effectively ignores it (it sets the "short term debt" to zero). When work becomes available, it starts paying attention again.


Thanks for the information. The Wiki does have a lot of information, but sometimes it can be a bit hard to understand if you're not too familiar with how things work. That's why I thought I'd ask here. I increased LHC's resource share, got BoincView to see the debt values, and you're right. It's asking for work from LHC, which is at zero short term debt, and the other projects I'm on seem to be cycling between each other as normal. So everything should be fine, and hopefully I'll be a bit more prepared for LHC's next batch of work. (I could increase the resource share even more than I did, but I'll test that out over time to see what I want it to be.)
ID: 13746 · Report as offensive     Reply Quote
BiloxiPete

Send message
Joined: 29 Mar 06
Posts: 7
Credit: 202,434
RAC: 0
Message 13747 - Posted: 26 May 2006, 1:56:29 UTC - in response to Message 13735.  


Keep your cache as small as possible.


Yes, well, there are always the idiots that think bigger is better.
Personally, I reckon they're compensating for something.


(you're right, Steve, they are greedy little antisocial pigs)


Oink, Oink
ID: 13747 · Report as offensive     Reply Quote
Profile anarchic teapot
Avatar

Send message
Joined: 15 Feb 06
Posts: 67
Credit: 460,896
RAC: 0
Message 13751 - Posted: 26 May 2006, 7:18:48 UTC - in response to Message 13747.  

Oink, Oink


Average turnaround time 8.28 days on a 2.2 GHz machine?

What do you do, switch it off for a week when the WUs go out so that you can be the last to report?

Actually, I must apologise for my previous statement. It was grossly unfair to pigs.

sQuonk
Plague of Mice
Intel Core i3-9100 CPU@3.60 GHz, but it's doing its bit just the same.
ID: 13751 · Report as offensive     Reply Quote
Gaspode the UnDressed

Send message
Joined: 1 Sep 04
Posts: 506
Credit: 118,619
RAC: 0
Message 13752 - Posted: 26 May 2006, 9:07:38 UTC - in response to Message 13736.  


Keep your cache as small as possible.

Maybe a little less name-calling and a little more focus on the topic might be in order.



Gaspode the UnDressed
http://www.littlevale.co.uk
ID: 13752 · Report as offensive     Reply Quote
Bill Hepburn

Send message
Joined: 18 Sep 04
Posts: 10
Credit: 5,151,492
RAC: 33
Message 13756 - Posted: 26 May 2006, 21:03:34 UTC - in response to Message 13752.  



Maybe a little less name-calling and a little more focus on the topic might be in order.



I must agree with that.

If the project percieves a problem, they can readily change the deadline, or the maximum number of units issued, or whatever. They haven't seen the need.

Boinc stats shows about 68k hosts attached to LHC. If the project issues 50k work units and sends each one out to 5 hosts, each hosts' "fair share" would be a bit less than 4.

If a user sets their preference to any value within the allowable range, that does not make them "a pig". It may indicate that they are unwise, but I don't think we can draw any further conclusions. They set their preferences to a value within the range that made sense to them.

ID: 13756 · Report as offensive     Reply Quote
Profile clownius
Avatar

Send message
Joined: 1 May 06
Posts: 34
Credit: 64,492
RAC: 0
Message 13767 - Posted: 28 May 2006, 11:26:27 UTC

Personally this is how i have started doing LHC. It has an over 50% resource share on boinc. I generally run a 0.1 day cache as im on a DSL connection..
1.Im sitting at my computer and notice LHC has work.
2.I suspend all other project and bump cache to 10 days.
3.Until the work runs out i leave cache at 10 days and only run LHC.
4.LHC has no work.
5.Cache goes back to 0.1 days and i allow a very low proirity project to fetch work.
6.I run out of LHC work and switch all other projects back on.

On average my huge 10 day cache lasts...oh about 2 days so results still come back very quickly and i get maximum work crunched for LHC whenever it has work to do.
ID: 13767 · Report as offensive     Reply Quote
m.mitch

Send message
Joined: 4 Sep 05
Posts: 112
Credit: 1,899,789
RAC: 1,130
Message 13769 - Posted: 28 May 2006, 15:40:17 UTC


Ah yes, I've seen you rocketing up the stats! What is now, 400, 450 credits ;-)




Click here to join the #1 Aussie Alliance on LHC.
ID: 13769 · Report as offensive     Reply Quote
Gaspode the UnDressed

Send message
Joined: 1 Sep 04
Posts: 506
Credit: 118,619
RAC: 0
Message 13770 - Posted: 28 May 2006, 15:59:58 UTC - in response to Message 13767.  
Last modified: 28 May 2006, 16:00:32 UTC

Personally this is how i have started doing LHC. It has an over 50% resource share on boinc. I generally run a 0.1 day cache as im on a DSL connection..
1.Im sitting at my computer and notice LHC has work.
2.I suspend all other project and bump cache to 10 days.
3.Until the work runs out i leave cache at 10 days and only run LHC.
4.LHC has no work.
5.Cache goes back to 0.1 days and i allow a very low proirity project to fetch work.
6.I run out of LHC work and switch all other projects back on.

On average my huge 10 day cache lasts...oh about 2 days so results still come back very quickly and i get maximum work crunched for LHC whenever it has work to do.


Why on earth go through all this rigmarole. Why not set LHC at, say, 80% resource share, and cache at 0.1 day. Enable all projects. Leave well alone.

BOINC will manage the work fetch cycle based on your cache size and you'll get loads of work for LHC when it's there. There won't be any work hoarded, so others can do it. Work will get done quicker overall.

Oh - I see the problem now: you might not get as many of those rare and valuable LHC credits to spend on goodies in the local shopping mall. You'll have more credits from other projects but I guess they aren't worth as much.

What's that? You can't spend the credits? Oh my...


Gaspode the UnDressed
http://www.littlevale.co.uk
ID: 13770 · Report as offensive     Reply Quote
Profile clownius
Avatar

Send message
Joined: 1 May 06
Posts: 34
Credit: 64,492
RAC: 0
Message 13776 - Posted: 29 May 2006, 5:44:45 UTC - in response to Message 13770.  


On average my huge 10 day cache lasts...oh about 2 days so results still come back very quickly and i get maximum work crunched for LHC whenever it has work to do.


Why on earth go through all this rigmarole. Why not set LHC at, say, 80% resource share, and cache at 0.1 day. Enable all projects. Leave well alone.

BOINC will manage the work fetch cycle based on your cache size and you'll get loads of work for LHC when it's there. There won't be any work hoarded, so others can do it. Work will get done quicker overall.

Oh - I see the problem now: you might not get as many of those rare and valuable LHC credits to spend on goodies in the local shopping mall. You'll have more credits from other projects but I guess they aren't worth as much.

What's that? You can't spend the credits? Oh my...

[/quote]

Actually if u wish to reread my post i do it this way to crunch maximum work when available and as fast as possible. I give up the credit on other project to crunch this one as quickly as possible and return as fast as possible.

I personally feel this project has better scientific cred than the other projects i crunch and so i dedicate my entire computer to it when it needs crunching.
This isnt a credit race!! Its purely using my computer for the project i feel is the most important.

Seriously though im guessing saying nasty things to others make u feel good so fire away im very thick skinned and i like making others happy.
ID: 13776 · Report as offensive     Reply Quote
Gaspode the UnDressed

Send message
Joined: 1 Sep 04
Posts: 506
Credit: 118,619
RAC: 0
Message 13777 - Posted: 29 May 2006, 7:45:57 UTC - in response to Message 13776.  

Seriously though im guessing saying nasty things to others make u feel good so fire away im very thick skinned and i like making others happy.


No offence intended. This was a gentle dig aimed at the 'credit-racers', of whom you claim you're not one. But judging by your sensitivity to it I'd guess that you are 'racing' more than you let on.


Gaspode the UnDressed
http://www.littlevale.co.uk
ID: 13777 · Report as offensive     Reply Quote
Profile John Hunt

Send message
Joined: 13 Jul 05
Posts: 133
Credit: 162,641
RAC: 0
Message 13778 - Posted: 29 May 2006, 8:12:04 UTC

Hey, who's bothered?
There are plenty of projects on BOINC to keep your PC busy...........


ID: 13778 · Report as offensive     Reply Quote
Profile Trog Dog

Send message
Joined: 25 Nov 05
Posts: 39
Credit: 41,119
RAC: 0
Message 13779 - Posted: 29 May 2006, 11:22:20 UTC - in response to Message 13777.  



No offence intended. This was a gentle dig aimed at the 'credit-racers', of whom you claim you're not one. But judging by your sensitivity to it I'd guess that you are 'racing' more than you let on.



You're obviously not "in it" for the credits, so what does it matter how many hoops someone else jumps through to get work?

Personally, I can't be bothered micro-managing BOINC, my cache is set to .1 (except the pc's at work where they only crunch and connect after hours and the cache is set to .5)with a resource share of 1000 the other projects I crunch for have a resource share of 100 or less.

I'm in it for the credits, but if credits/hour was all that I was chasing then I'd stick to Einstein with an Akos app, and be whining about the lack of wu's.

No offence intended, but maybe you're more interested in credits than you like to let on, afterall if you're only interested in the science what's the problem, the wu's are getting crunched ie. the science is getting done.
ID: 13779 · Report as offensive     Reply Quote
MB Atlanos

Send message
Joined: 14 Jul 05
Posts: 11
Credit: 81,274
RAC: 0
Message 13780 - Posted: 29 May 2006, 12:40:09 UTC - in response to Message 13779.  



You're obviously not "in it" for the credits, so what does it matter how many hoops someone else jumps through to get work?

...

No offence intended, but maybe you're more interested in credits than you like to let on, afterall if you're only interested in the science what's the problem, the wu's are getting crunched ie. the science is getting done.


Sense of fairness I guess, why should a minority of greedy numberhunters grab a considerable piece of already limited work? This hampers the participation for the rest of us, who's majority consider credits as a nice bonus but finally really unimportant.

Oh we have definitely a delay in completion, thanks to big-cache-junkies who mainly crunch for there personal benefit (how silly it even may) and the inadequacies of the boincsystem to counteract WU-crabbers.
Remember, currently we do not have an Admin for this projekt, to adjust the limits, if there even are an awareness of this problem at CERN.

Unfortunatly LHC and Einstein are the only "hard science" (physics) projekts in non-alpha/beta stage. And its needs the completion of the current work to issue the next one.
ID: 13780 · Report as offensive     Reply Quote
Previous · 1 · 2 · 3 · 4 · 5 . . . 11 · Next

Message boards : Number crunching : I think we should restrict work units


©2024 CERN