Processing *within* project in FIFO order rather than deadline order #2

Message boards : Number crunching : Processing *within* project in FIFO order rather than deadline order #2
Message board moderation

To post messages, you must log in.

AuthorMessage
nsandersen

Send message
Joined: 3 Apr 99
Posts: 6
Credit: 821,167
RAC: 0
United Kingdom
Message 1912003 - Posted: 9 Jan 2018, 9:46:07 UTC

I will mention this once more and then suppress it in whatever sense, Freudian or otherwise.. :)

Looking back at this one (can't seem to post there any more?): https://setiathome.berkeley.edu/forum_thread.php?id=82014

Following the suggestion I set it to "Maintain enough work for an additional" 1 day.

It has now taken 115 work units of various kinds, estimated at ~110h of processing. 1/3 of this is GPU jobs. So the remaining ~70h are CPU only jobs. Its CPU time allowance is 25%, so these will take ~280h and it appears that for "1 day" it has downloaded work for over 300h real time.

Does the scheduler take the CPU time fraction setting into account? Even then it is way over the cache setting unless we are talking about another parameter.


There is time for all of this before the deadlines, but about 1/4 of the jobs look to be dropped as it is taking the ones with 5 weeks to the deadline before the ones with 2-3 days..

No problem as such for me, but I imagine it means you get a smaller proportion of things done by the deadlines set. Perhaps not so important for SETI, but for other projects?
ID: 1912003 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13727
Credit: 208,696,464
RAC: 304
Australia
Message 1912004 - Posted: 9 Jan 2018, 10:01:40 UTC - in response to Message 1912003.  

Following the suggestion I set it to "Maintain enough work for an additional" 1 day.

What is your "Store at least" number?
Generally the larger the value you set for "Maintain enough work for an additional" the longer it takes before it returns & gets new work, and so the more work it will get with such a request.
If you want a cache of a particular size, it is best to set that value using "Store at least" and set the "additional work" value to something like 0.04 (just under 1 hr).


Also the current WUs will take much less time to process than the WUs you appear to have previously processed, so it won't take nearly as long as you might think to process them.
It will, however, take quite some time before the Estimated time comes back in to line with the actual processing time.
Grant
Darwin NT
ID: 1912004 · Report as offensive
nsandersen

Send message
Joined: 3 Apr 99
Posts: 6
Credit: 821,167
RAC: 0
United Kingdom
Message 1912008 - Posted: 9 Jan 2018, 10:37:40 UTC - in response to Message 1912004.  

"Store at least.." != "Maintain enough work for an additional.."? Sorry, I am not sure which setting you mean, but I will try a fraction on the latter.

The SETI estimated times are very close to the actual run times on my machine (but yes, I have seen very big differences and lags of at least half a year for the times to get into line on other projects).

Thank you.
ID: 1912008 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13727
Credit: 208,696,464
RAC: 304
Australia
Message 1912063 - Posted: 10 Jan 2018, 4:41:10 UTC - in response to Message 1912008.  
Last modified: 10 Jan 2018, 5:14:15 UTC

"Store at least.." != "Maintain enough work for an additional.."? Sorry, I am not sure which setting you mean, but I will try a fraction on the latter.

In Computing preferences, in the Other section, they are 2 different settings.
Store at least xx days of work- use this one to set your cache, 4 for 4 days, 1 for 1 day.
Store up to an additional xx days of work- use this one to minimize the amount of work downloaded at any given time, and to report & request work as soon as possible, 0.04 is a good general number to use.

The SETI estimated times are very close to the actual run times on my machine

They might have been before (you last downloaded Seti work in Dec- scratch that, you downloaded some work a couple of days ago but then you aborted it. Aborting things doesn't help with run times & estimates & resource shares), but the current WUs have much shorter run times than their initial estimates. My systems are doing them in almost half the initial estimated time (as those estimates were based on the earlier much longer running WUs).
On my main system the estimates are now almost correct, my slower system will take another week or 2 before that happens.
Grant
Darwin NT
ID: 1912063 · Report as offensive
nsandersen

Send message
Joined: 3 Apr 99
Posts: 6
Credit: 821,167
RAC: 0
United Kingdom
Message 1912082 - Posted: 10 Jan 2018, 9:01:51 UTC - in response to Message 1912063.  

Great, thank you.

The reason I aborted the last ones was that I want to try an account manager and I couldn't get it to take over management of my existing account/session, so I had to draw a line and just let it finish the units it had started.
ID: 1912082 · Report as offensive

Message boards : Number crunching : Processing *within* project in FIFO order rather than deadline order #2


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.