When downloaded to my desktop, a fresh WU's "time to completion" was about 7hrs, now it has gone up to 08:39:29 - quite a difference!

---

WinXP Home, P4 3.2GHz HT, 512Mb RAM. Running SETI, Predictor, Prime Grid, SIMAP, Folding

noticable diffrence here too, have 2 machines running seti:

3.2 PCI-E w/ 1gig dual ram & 10,000 rpm sata drive
Used to take just above or below 3 hours for each, now its 5:20-6 hrs for each.


2.4 P4, 512 ram & 7200 rpm IDE drive
Used to take 4:30-5 hrs, now taking 5:30-6 hrs.

---

> Computer programs can only have a limited amount of intellegence built into
> them (otherwise they just start getting bigger and bigger as you slap more
> 'intellegence' into them). If the complexity of your environment is too much
> for the program's current algorithm used to calculate the cache size, you may
> need to do some tweaking until it works right for you.
>
> It's impossible to write a program that can handle every single user's
> environment...they write it to handle the vast majority of users. Users who
> fall outside of the norm have to take some responsibility for adjusting the
> preferences to suit their needs (that's why they're Preferences, not
> hard-coded values!)
>
> If the value you give it results in WUs staying in your cache beyond the
> timeout period, then CHANGE THE VALUE TO SOMETHING LOWER!

1. I am a programmer. I know all this. Stop preaching.

2. Please note that BOINC is not operating normally. That's what this entire thread is about.

3. I probably fall in the realm of "the vast amount of users"

4. Changing the value to something lower DOES NOT SOLVE THE PROBLEM. I already said this.

Next.

---

> > Computer programs can only have a limited amount of intellegence built
> into
> > them (otherwise they just start getting bigger and bigger as you slap
> more
> > 'intellegence' into them). If the complexity of your environment is too
> much
> > for the program's current algorithm used to calculate the cache size, you
> may
> > need to do some tweaking until it works right for you.
> >
> > It's impossible to write a program that can handle every single user's
> > environment...they write it to handle the vast majority of users. Users
> who
> > fall outside of the norm have to take some responsibility for adjusting
> the
> > preferences to suit their needs (that's why they're Preferences, not
> > hard-coded values!)

> > If the value you give it results in WUs staying in your cache beyond the
> > timeout period, then CHANGE THE VALUE TO SOMETHING LOWER!
>
> 1. I am a programmer. I know all this. Stop preaching.
>
> 2. Please note that BOINC is not operating normally. That's what this entire
> thread is about.
>
> 3. I probably fall in the realm of "the vast amount of users"
>
> 4. Changing the value to something lower DOES NOT SOLVE THE PROBLEM. I
> already said this.
>
> Next.


TO ANYONE WHO CARES:

WU'S ARE TAKING LONGER (ACTUAL TIME DEPENDING ON THE MACHINES BEING USED)
MORE PROCESSING TIME = LESS WORK (ADMIN SURE DOESN'T SAY OTHERWISE)

MORE WORK = MORE HAPPY PPL (CAN'T WAIT FOR PREDICTOR TO GO BACK ONLINE)

---

> This means that the WUs are actually taking about three hours more to finish
> than what BOINC is estimating. This is a problem because BOINC uses these
> estimates to determine how many WUWUWUWUs to download. Since it's
> underestimating how long it'll take to finish a WU, it's downloading more WUs
> than it can actually handle. This in turn means that the last few WUWUWUWUs
> of the batch are going to be returned after the deadline, and thus discarded.
>
> And I can't really think of anything that'll make that stop.


Reducing your cache size works 100% of the time.

---

> > This means that the WUs are actually taking about three hours more to
> finish
> > than what BOINC is estimating. This is a problem because BOINC uses
> these
> > estimates to determine how many WUWUWUWUs to download. Since it's
> > underestimating how long it'll take to finish a WU, it's downloading more
> WUs
> > than it can actually handle. This in turn means that the last few
> WUWUWUWUs
> > of the batch are going to be returned after the deadline, and thus
> discarded.
> >
> > And I can't really think of anything that'll make that stop.
>
>
> Reducing your cache size works 100% of the time.
>

You say,reducing cache size. Here's a noobie quest. Where exactly? It seems that i can not find it. :/
Regards

> You say,reducing cache size. Here's a noobie quest. Where exactly? It seems
> that i can not find it. :/

Go to Your Account, click on View or Edit General Preferences.
Set "Connect to network about every X days" to the number of days worth of work you wish to cache.
3-14 (depending on your processing time) are reasonable values to use.
3 if it's taking you 10+ hours per work unit, 14 if you're knocking them over in less than 3 hours.
Either way you should be able to continue working through any outages, but not go past the "Report deadline".

---

Grant
Darwin NT

>
>
> Reducing your cache size works 100% of the time.
>

Good lord. Do people just not read anymore?

---

@Papa Zito:
>
> 1. I am a programmer. I know all this. Stop preaching.
>
OK, fine...I didn't know that...so am I (mainframe, not PC). I wasn't trying to 'talk down' to you. Many other people who use these forums are programers too, but most probably aren't and might not understand the concept I was getting at unless it's spelled out to them. My replies are meant to be inclusive of the broader audience as well as (you) the poster. No offence was intended.
>
> 2. Please note that BOINC is not operating normally. That's what this entire
> thread is about.
>
Agreed.
>
> 3. I probably fall in the realm of "the vast amount of users"
>
If you've tried reducing your cache and are still downloading WUs that can't be crunched before they expire, maybe you need to reduce it further. If your cache still has WUs in it that are expired, they'll either have to work their way out or you could reset your project to clear them (not recommended as it's unfair to other users if you have WUs that are not yet expired and you COULD crunch them before the deadline...it would sure be nice if we could delete individual WUs in this circumstance).
>
> 4. Changing the value to something lower DOES NOT SOLVE THE PROBLEM. I
> already said this.
>
If you're referring to #2, again I agree. What I was offering was a circumvention so you (Papa Zito specifically) and anyone else who is unintentionally going past the deadline, would have a course of action to follow UNTIL Berkley fixes #2.
>
> Next.
>
If the circumvention doesn't work for you, that's another subject.