Look folks.........
Anything that disenfranchises anybody for any reason on purpose is just NOT gonna happen here.
They have enough problems right now keeping the able bodied kitties supplied with work.

I think NASA would have a tough time keeping you supplied with work! ;)

The issue of cutting off the old and slow by lowering the expiration times is the same argument for cutting off old BOINC clients. "Anyone using a really old version makes me loose 0.00015% of the credit I would otherwise get! So we should set a minimum version." They return good science results so there is no reason they shouldn't keep processing work. Same with the slower processors.

If the longest anyone is taking now is < 5 weeks I wouldn't see an issue from changing the default 6 weeks down to 5. However I bet there are a few machines out there taking 5 weeks and 6.75 days to get though some work.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

... I think central command should try to trim the expiration date as an experiment and measure the benefits. ...

i concur, 60 day expiration dates is ridiculous.

anyone notice results generation is near zero again!!! gab them quick while ya can, project is going down.

---

... I think central command should try to trim the expiration date as an experiment and measure the benefits. ...

i concur, 60 day expiration dates is ridiculous.

anyone notice results generation is near zero again!!! gab them quick while ya can, project is going down.

The kitties are not eating the crickets yet.......

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

If it's any indication, I just checked my top rig. Stats here are still turned off, but I used Fred's rescheduler just to sniff the cache.
It's full up......and better news is the GPU cache is only about 1/3 shorties.
So, even if things snap, it's good to go for a day or so anyway.
Not what I should like to see cached, but better than a poke in the eye with a sharp stick.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

... better than a poke in the eye with a sharp stick.

---

I dont see that trimming the expiry date would disenfranchise users, even those with 'very' old rigs..

It 'might' mean that 'some' users would have to accept smaller amounts of WU at a time to process, just sufficient to process in the time available.

It might make everyones d/loads easier in fact if smaller amounts were being taken at any one time by people.

Those old and slow machines would still be able to contribute to the job in hand, just that they would'nt be able to hold tons of WU in reserve.

If the present expiry is 6 weeks or more then decreasing to 5 weeks should'nt cause a major problem.

Particularly if it were to be implemented for a trial period to see just what the possible benefits and drawbacks are.

My tuppence worth, since I seem to have started this furball off:-)

Regards,

---

Cliff,
Been there, Done that, Still no damm T shirt!

anyone notice results generation is near zero again!!! gab them quick while ya can, project is going down.

Yep it's down but that's because there is over a quarter million ready to send (that will pick up if it drops below that number) and I'm only picking up a few at a time since yesterday as I'm still bouncing off the limits. :)

Cheers.

---

anyone notice results generation is near zero again!!! gab them quick while ya can, project is going down.

Yep it's down but that's because there is over a quarter million ready to send (that will pick up if it drops below that number) and I'm only picking up a few at a time since yesterday as I'm still bouncing off the limits. :)

Cheers.

Best I can tell from casual observations without any real digging is like this:

If it drops below 200k results ready to send, a splitter or splitters fire up and chew threw a channel. If that brings it back over 200k, then they go back to sleep and wait for it to drop below 200k again. If it gets significantly below 200k and the splitters still haven't woken up, then worry :)

---

I dont see that trimming the expiry date would disenfranchise users, even those with 'very' old rigs..

It 'might' mean that 'some' users would have to accept smaller amounts of WU at a time to process, just sufficient to process in the time available.

The last time the project made that kind of adjustment in February 2008, it increased the host requirement from 30 Whetstone MIPS to 40 (crunching 24/7). That disenfranchised some 700+ hosts according to Eric Korpela, though I don't know if he derived that from all hosts ever attached to SETI_BOINC or only those which were still active then.

Somebody with a broadband connection and willing to do some work could download the hosts stats export and figure out how many would be disenfranchised by any proposed change. Doubling to 80 Whetstone MIPS would halve the deadlines.

                                                                   Joe

I dont see that trimming the expiry date would disenfranchise users, even those with 'very' old rigs..

It 'might' mean that 'some' users would have to accept smaller amounts of WU at a time to process, just sufficient to process in the time available.

It might make everyones d/loads easier in fact if smaller amounts were being taken at any one time by people.

Those old and slow machines would still be able to contribute to the job in hand, just that they would'nt be able to hold tons of WU in reserve.

Due to the length of time it takes us old/slow machines to complete a WU (APR/DCF), and the maximum cache size BOINC allows, we CAN'T hold "tons" of tasks, only tens or at most hundreds. I am CPU-only (not GPU-capable), keep a 3-day cache, and as best Ii can recall, have never had more than 8 Tasks on either box, even during "shorty" storms.

We old/slow guys are not the cause of the bandwidth and download problems.

---

Donald
Infernal Optimist / Submariner, retired

Hi Joe,

While I do have a broadband 20Mbps connection, it doesnt seem to cross the pond too well:-/ I suffer from the usual problem of dropped conncetions, http errors and frozen downloads. Nor do I have the expertise to analyse the data.

However would increasing the CPU share of the load from .04 to .20 in tasks be of use?

I notice that E@H is set to do that.. However I have no idea how that affects things in real terms.

Cheers,

---

Cliff,
Been there, Done that, Still no damm T shirt!

We old/slow guys are not the cause of the bandwidth and download problems.

Nope.
But the long time it takes for such systems to complete work results in problems with the database size. The bigger it is, the more it tends to trip over itself.

---

Grant
Darwin NT

However would increasing the CPU share of the load from .04 to .20 in tasks be of use?

I notice that E@H is set to do that.. However I have no idea how that affects things in real terms.

That relates to the processing of data, nothing to do with donwloads or uploads.

---

Grant
Darwin NT

My single-core machine is nowhere near fast, but it does well enough. A 2.5-day cache is ~8 VLARs, or ~20 shorties, or ~14 "average" MBs. A 10-day cache of AP is about 5.

Not that we're trying to discourage anyone from participating, but realistically.. if a computer can't do a single MB in less than 24 hours (actual crunching time, not turn-around time), buh-bye. If it means helping the database be as lean as it can be and not have to wait ~40 days for a task to complete, then so be it.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

If for some reason you had access to a database containing more than 2 billion result lines, would it not be that tempting just sorting on the different scores with of course the highest ones (best ones) coming first?

If so, perhaps something of interest might be readily visible this way. I guess it is quite an experience doing such a thing at times. Probably the different candidates show up in this way as well.

how do we have access to that database ?

not till than there is begin workday in the Berkeley :)

---

> 20581835 is a pretty nice number ... it has 8 digits...

Are you perhaps meaning that it has a score (gaussian perhaps) of 8 digits?

If so, it definitely must rank among the candidates.

Don't forget we are doing quite well for being a civilization in space ourselves. Currently we are the only one that is known to be existing.

Yup, I'm aware it has to do with data processing..does it make it faster or slower?
Faster WU = more WU in less time.. like shorties:-)
These DO affect uploads and downloads.

Cheers,

---

Cliff,
Been there, Done that, Still no damm T shirt!

Yup, I'm aware it has to do with data processing..does it make it faster or slower?
Faster WU = more WU in less time.. like shorties:-)
These DO affect uploads and downloads.

Cheers,

The 0.04 and 0.20 figures are used for Boinc's internal use, increase the values too far and Boinc will run one less CPU task,
Cuda, CAL, Brook+ and OpenCL apps will use what CPU they require, changing the 0.04 to 0.20 won't have a direct impact on their speed,

Claggy

Hi Claggy,
Thanks, dont know much about the in[f]ternal workings of Boinc or the drivers.

Cheers,

---

Cliff,
Been there, Done that, Still no damm T shirt!