LHC@home

Did anyone clock how fast those 13500 work units were snapped up? I got ONE, and by the time it had run for 15 minutes there was no more work (of course, my WU may not have started right away because I crunch for other projects.)

Well anyway, hooray for the drizzle after the drought!

---

_______

"Three quarks for Muster Mark!"
. . . . . . . - James Joyce, Finnegans Wake . . . .

Ok, that explaines why I haven't been able to get any wu's on the last two runs!Some days you'er the windshield, some days you'er the bug!

---

A clear conscience is usually the sign of a bad memory

I got 19 from this batch, and I thought that wasn't alot. They were all gone within an hour of when my computer began downloading the ones I got. I see in the results history that I've gotten a couple of others this month that I was completely unaware of.

I got 19 from this batch, and I thought that wasn't alot. They were all gone within an hour of when my computer began downloading the ones I got. I see in the results history that I've gotten a couple of others this month that I was completely unaware of.

You're pretty brave admitting you got 19. I got two- is there a particular setting to help this? My network usage/work cache is set to 1 day - is 5 better to encourage more WU's?

Did anyone clock how fast those 13500 work units were snapped up? I got ONE, and by the time it had run for 15 minutes there was no more work (of course, my WU may not have started right away because I crunch for other projects.)

Well anyway, hooray for the drizzle after the drought!

I wonder why I was given 13,410 of them?

Oh well... I have work >:P

---

I disabled work requests on this project.
I don't like the idea that somebody, sometimes throws me peanuts.

---

Do you want to get banned for 31 years, your account and credits deleted at a Boinc project ? Predictor@home is your best choice.

I got two- is there a particular setting to help this? My network usage/work cache is set to 1 day - is 5 better to encourage more WU's?

My cache setting is at 0.5 days, if that does anything good it just means that my computer might check more often for work. I was just lucky and my computer happened to check at the time when there were some WUs available. I think it also helps if you have a fast DSL or cable connection so the cache fills before the WUs are gone, they really do get gone fast.

I happened to be at my computer when this happened and I though about changing my cache settings to a much larger value, like 5 days, just to fill the cache, but I think that's just rude to the other people here. No, I was just lucky to get the few WUs I got.

I disabled work requests on this project.
I don't like the idea that somebody, sometimes throws me peanuts.

What's wrong with peanuts? :-)

:-) Nothing wrong with peanuts, but i for one have gotten sick and tired of hanging around for those peanuts;-) so missed out on the peanuts:-) LoL.
Regards
Masud.

---

...I see in the results history that I've gotten a couple of others this month that I was completely unaware of.

@Bob Guy: Same here. This happens a lot ESPECIALLY if your machine has a fast processor: Gone in a flash, Downloaded in a flash, Crunched in a flash, Reported in a flash.

...I got two- is there a particular setting to help this? My network usage/work cache is set to 1 day - is 5 better to encourage more WU's?

@Ravens: I've experimented with different cache settings (from 0.1 to 7) and my labors have revealed that 3 days is pretty good. Less than 3 will usually cause your machine to pick up very few (or ONE) work units even if the run is huge [ >50000 ]. A cache number more than 3 will result in often getting NOTHING from small runs [ <20000 ] ...but I encourage others to tweak my number and post if they find a better Magic Constant!

P.S. I love peanuts, and I don't mind waiting around for them.

---

_______

"Three quarks for Muster Mark!"
. . . . . . . - James Joyce, Finnegans Wake . . . .

Pardon my ignorance, but where does one 'adjust the cache settings'?
Thanks,
Joe

...I see in the results history that I've gotten a couple of others this month that I was completely unaware of.

@Bob Guy: Same here. This happens a lot ESPECIALLY if your machine has a fast processor: Gone in a flash, Downloaded in a flash, Crunched in a flash, Reported in a flash.

...I got two- is there a particular setting to help this? My network usage/work cache is set to 1 day - is 5 better to encourage more WU's?

@Ravens: I've experimented with different cache settings (from 0.1 to 7) and my labors have revealed that 3 days is pretty good. Less than 3 will usually cause your machine to pick up very few (or ONE) work units even if the run is huge [ >50000 ]. A cache number more than 3 will result in often getting NOTHING from small runs [ <20000 ] ...but I encourage others to tweak my number and post if they find a better Magic Constant!

P.S. I love peanuts, and I don't mind waiting around for them.

Pardon my ignorance, but where does one 'adjust the cache settings'?
Thanks, Joe

Go to your account, General preferences, Network usage.
Adjust your 'Connect to' time to whatever you think is appropriate. For this project my opinion is that 1 day or less is most appropriate. And I like peanuts! I'll wait awhile to get some.

As noted before large 'connect to' times can cause you to completely miss small distributions of work, but if you happen to ask for work at just the right time a large 'connect to' time will get you more WUs downloaded.

You cannot actually adjust your cache size as in number of WUs downloaded but you can set a 'connect to' time large enough so that more WUs will be downloaded when work is available. There are also ways to fake-out the server (to get more work than your settings would ordinarily allow) but I consider that to be unfair to the other people here who would also like to get some work.

Also note that setting your cache here is a global setting and will be applied in any other Boinc project that you are active in.

...I've experimented with different cache settings (from 0.1 to 7) and my labors have revealed that 3 days is pretty good. Less than 3 will usually cause your machine to pick up very few (or ONE) work units even if the run is huge [ >50000 ]. A cache number more than 3 will result in often getting NOTHING from small runs [ <20000 ] ...but I encourage others to tweak my number and post if they find a better Magic Constant!

Using 4 or 5 will work if you do the following:


1. Give lhc@home at least 75% resource share on any given machine.

2. Don't crunch for too many projects on any one machine, but make sure you crunch for at least one other project on each machine - Climate Prediction, Climate Attribution, SETI, Einstein, Rosetta, and the like are good candidates.

3. Keep an eye on the "other" projects running alongside lhc; they may have greedy tendencies that will block out lhc (even with a 0.01% resource share.. yes, I've seen it happen.)

4. Run your machine to death. You will get more lhc WUs if your machine has been crunching like crazy for other project(s) during lhc droughts.


That's my word.

---

Ariel: Certified "Too Cute for LHC" Cruncher!


. . . . . . . . . . . . -- Consider the lilies.

Pardon my ignorance, but where does one 'adjust the cache settings'?
Thanks, Joe

Go to your account, General preferences, Network usage.
Adjust your 'Connect to' time to whatever you think is appropriate. For this project my opinion is that 1 day or less is most appropriate. And I like peanuts! I'll wait awhile to get some.

Just to point out a small discrepancy, the "Connect to" time is not a "cache" setting. Although it does affect how much work is stored locally, it is not a "cache" setting. This is a very common misunderstanding.

Jim

---

...Although it does affect how much work is stored locally, it is not a "cache" setting. This is a very common misunderstanding.

And I suppose the amount of work stored locally is not a work cache. If that is so, then the Ulysses S. Grant in my wallet isn't cash either. That would explain why the liquor store down the street won't sell me that bottle of Patron Silver. Give me a break, Jim. It all comes down to cache, whether it bites you in the butt or not.

---

_______

"Three quarks for Muster Mark!"
. . . . . . . - James Joyce, Finnegans Wake . . . .

...Although it does affect how much work is stored locally, it is not a "cache" setting. This is a very common misunderstanding.

And I suppose the amount of work stored locally is not a work cache. If that is so, then the Ulysses S. Grant in my wallet isn't cash either. That would explain why the liquor store down the street won't sell me that bottle of Patron Silver. Give me a break, Jim. It all comes down to cache, whether it bites you in the butt or not.

Yes, the work stored locally is a cache, but the "connect interval" is just that, a connect interval, NOT a cache setting.

---

Yes, the work stored locally is a cache, but the "connect interval" is just that, a connect interval, NOT a cache setting.

So... a horse isn't a horse if it's a vial of stud spew that's worth $150,000 on the black market. Is that right? If there's any doubt, ask anyone who frequents the local pony track. That goo is worth some serious cash; don't try to tell the bookies it's not a horse!

---

_______

"Three quarks for Muster Mark!"
. . . . . . . - James Joyce, Finnegans Wake . . . .

Indeed...

It is a common misunderstanding that "Connect to Network every X days" was not the Cache setting.

Apart from correction values applied to it (Up Fraction, Online Fraction, Running Fraction etc.) it is the basic - and only - local Cache setting to date.
Other supplemental Cache Options are being introduced with the current 5.9.x Alpha test series.

Why they erroneously named it so misleading (as the Client will make much more frequent contact when online, regardless of this alledged Network limitation setting) is beyond me.

---

Scientific Network : 45000 MHz - 77824 MB - 1970 GB

Indeed...

It is a common misunderstanding that "Connect to Network every X days" was not the Cache setting.

Apart from correction values applied to it (Up Fraction, Online Fraction, Running Fraction etc.) it is the basic - and only - local Cache setting to date.
Other supplemental Cache Options are being introduced with the current 5.9.x Alpha test series.

Why they erroneously named it so misleading (as the Client will make much more frequent contact when online, regardless of this alledged Network limitation setting) is beyond me.

If it was indeed a cache setting, the "connect interval" would be directly proportional to the cache setting. This is not always the case. In some instances it is directly proportional, while in others, making the "connect interval" too large will actually stop the accumulation of work on hand; therefore it is NOT a cache setting. Yes, it does affect the cache, but it is NOT a cache setting.

---

*lol*

Okidok, so tell me where the Setting for the Local Cache is then ?
Because apparently, I've been running BOINC without knowing how to set it for more than 2 years ;)

The answer :
The setting is of course directly proportional to the Cache.

However, it is smart enough to detect Situations where the selected amount of Cached work will result in Problems (such as missing the deadline for short-deadline Projects). This is a safety function with override Priorities inherent to the Cacheing feature, but nonetheless it remains exactly that : Set Cache to x Days worth of work.

It's actually smart enough to correct for System downtimes, times where the System is up but not running BOINC and even CPU efficiency (where BOINC is running but only gets a fraction of the total CPU share).

Set your Cache to 1 day and after filling up the Cache, disconnect Network cables and use the System in the same way you did in the last 2 weeks. Magically, it will run dry in exactly the time you had set as Cache.

The effects of this calibration lead several folks to believe it was something else than Cacheing function, but it's plain not true.

Double your Setting and witness it downloading & Caching exactly double the Work... unless it determines that this would hit one of the Criteria mentioned above and its limiting-feature cuts in.

Exceptions were coded into BOINC for exceptional Projects, such as CPDN where the setting was rendered basically irrelevant and specific extensions had to be put in place to accomodate the extremely long runtimes.

---

Scientific Network : 45000 MHz - 77824 MB - 1970 GB