Message boards :
Number crunching :
Can't get new work
Message board moderation
Author | Message |
---|---|
Send message Joined: 18 Sep 04 Posts: 17 Credit: 53,515 RAC: 0 |
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 |
Send message Joined: 1 Sep 04 Posts: 506 Credit: 118,619 RAC: 0 |
<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 |
Send message Joined: 3 Oct 04 Posts: 19 Credit: 46,312 RAC: 0 |
<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. |
Send message Joined: 3 Aug 05 Posts: 49 Credit: 143,072 RAC: 0 |
<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 |
Send message Joined: 3 Oct 04 Posts: 19 Credit: 46,312 RAC: 0 |
<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. |
Send message Joined: 3 Aug 05 Posts: 49 Credit: 143,072 RAC: 0 |
<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 |
Send message Joined: 2 Sep 04 Posts: 545 Credit: 148,912 RAC: 0 |
<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. |
Send message Joined: 2 Sep 04 Posts: 39 Credit: 441,128 RAC: 0 |
<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). |
Send message Joined: 3 Oct 04 Posts: 19 Credit: 46,312 RAC: 0 |
<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. |
Send message Joined: 2 Sep 04 Posts: 39 Credit: 441,128 RAC: 0 |
<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. :-) |
Send message Joined: 25 Aug 05 Posts: 42 Credit: 3,518 RAC: 0 |
|
©2024 CERN