LHC@home

I'm not sure if this is an LHC, Seti or general BOINC question.

I am subscribed to LHC (100), Seti (100), Einstein (100) & CPDN (50). Cache is set to six days

Current status;
6 Seti units that won't upload, my CPDN is ticking over nicely, Einstein downloads abpout 6 units a week, runs them exclusively and then gets no more for about another week. No LHC units in progress and it won't request more. When I suspended my CPDN it downloaded one and then said 'Suspending work fetch because computer is overcommitted'. It is trying to request 514800s of work from Seti.

What gives? Why won't my machine download more LHC units?

Slainte,

David

---

<blockquote>
What gives? Why won't my machine download more LHC units?

</blockquote>

LHC is now issuing units with a deadline of around 5 days. With your cache set at six days the unit will have expired before your machine uploads the result to LHC. Reduce your cache size and you should get some work when your current queue reduces.

---

Gaspode the UnDressed
http://www.littlevale.co.uk

<blockquote><blockquote>
What gives? Why won't my machine download more LHC units?

</blockquote>

LHC is now issuing units with a deadline of around 5 days. With your cache set at six days the unit will have expired before your machine uploads the result to LHC. Reduce your cache size and you should get some work when your current queue reduces.

</blockquote>

Cache size is not the same as connection type or interval. Even though my cache size is 7 to 10 days, the PCs are always connected and should be uploading and downloading whenever a WU is finished.

This seems to be a problem in many of the recent BOINC verions.

---

<blockquote><blockquote><blockquote>
What gives? Why won't my machine download more LHC units?

</blockquote>

LHC is now issuing units with a deadline of around 5 days. With your cache set at six days the unit will have expired before your machine uploads the result to LHC. Reduce your cache size and you should get some work when your current queue reduces.

</blockquote>

Cache size is not the same as connection type or interval. Even though my cache size is 7 to 10 days, the PCs are always connected and should be uploading and downloading whenever a WU is finished.

This seems to be a problem in many of the recent BOINC verions.
</blockquote>

But if your cache size is set to 10 days you can't finish the last workunit you downloaded within the deadline limits. You just download too many workunits at the same time, the last workunits will be past the deadline by the time you want to process them.

May I ask you why you take such a big cache size when you are constantly connected because I can't really see the advantage.

---

BOINC.BE: The team for Belgians and their friends who love the smell of glowing red cpu's in the morning

<blockquote><blockquote><blockquote><blockquote>
What gives? Why won't my machine download more LHC units?

</blockquote>

LHC is now issuing units with a deadline of around 5 days. With your cache set at six days the unit will have expired before your machine uploads the result to LHC. Reduce your cache size and you should get some work when your current queue reduces.

</blockquote>

Cache size is not the same as connection type or interval. Even though my cache size is 7 to 10 days, the PCs are always connected and should be uploading and downloading whenever a WU is finished.

This seems to be a problem in many of the recent BOINC verions.
</blockquote>

But if your cache size is set to 10 days you can't finish the last workunit you downloaded within the deadline limits. You just download too many workunits at the same time, the last workunits will be past the deadline by the time you want to process them.

May I ask you why you take such a big cache size when you are constantly connected because I can't really see the advantage.</blockquote>

To be able to keep crunching when work disappears for days... the same reason caching add-ons were written for SETI-1. However, BOINC didn't implement caching properly - the cache size and connect interval need to be separate parameters.

---

<blockquote><blockquote>

May I ask you why you take such a big cache size when you are constantly connected because I can't really see the advantage.</blockquote>

To be able to keep crunching when work disappears for days... the same reason caching add-ons were written for SETI-1. However, BOINC didn't implement caching properly - the cache size and connect interval need to be separate parameters.
</blockquote>

The problem is that this project will always have a period of time where there is no work to crunch, that is the nature of this project, you can't do anything about that. You might have some work to do if you set your cache size big enough but everyone else would have to wait until you finished your results or until they redistribute the workunits that you have in your cache. The bigger your cache size is the longer the rest of us has to wait and the longer it takes before the scientists can analyse all the results that were returned. That is the reason why they opted for shorter deadlines, to get results in as soon as possible so the global downtime is minimised.

---

BOINC.BE: The team for Belgians and their friends who love the smell of glowing red cpu's in the morning

<blockquote>To be able to keep crunching when work disappears for days... the same reason caching add-ons were written for SETI-1. However, BOINC didn't implement caching properly - the cache size and connect interval need to be separate parameters.</blockquote>
Perhaps true. They probably should be separate parameters. This is a feature request that has been made, but it is not in the system yet. Until it is, we have to live with it. And, since you are running separate projects already, you have the biggest antidote to running out of work. We have had only one instance where more than 3 project were off line for a fairly long time (almost a full day). But, in general, the system as a whole runs better when people use smaller cache sizes.

In any event, not taking advice is your choice, but you will have to live with the consequences of that choice.

---

<blockquote>Cache size is not the same as connection type or interval.</blockquote>

At the moment though, it is the same. The cache size **is** the time between connections.

Also, LTD numbers seem to get more accurate (and less inflated) with a lower cache. If you have a constant connection anyway, try a 0.5 day connect time (or even 0.25).

---

<blockquote><blockquote>Cache size is not the same as connection type or interval.</blockquote>

At the moment though, it is the same. The cache size **is** the time between connections.

Also, LTD numbers seem to get more accurate (and less inflated) with a lower cache. If you have a constant connection anyway, try a 0.5 day connect time (or even 0.25).</blockquote>

NO - I will NOT play that game with cache size. It defeats the whole concept of a cache.

---

<blockquote>NO - I will NOT play that game with cache size. It defeats the whole concept of a cache.</blockquote>

Agreed, cache management could be better. But it is what it is at present. Saying that they are not the same thing is incorrect. They are the same thing, for now.

Saying they *shouldn't* be the same thing, I can get behind. :-)

---

Uploaded work 40 minutes ago no new work, is it because seti is now running?

---