Message boards :
BOINC client :
Project Priority Processing Manipulation
Message board moderation
Author | Message |
---|---|
Send message Joined: 19 Jan 07 Posts: 1179 |
That's strange. If it has a negative LTD, you shouldn't be getting work from it at all! |
Send message Joined: 29 Aug 05 Posts: 304 |
Your client thinks it will have trouble meeting the deadline on that task so it is running it at high priority. Running a task at high priority will cause the LTD and STD to go negative quickly, the client will not download work from that project for some time after to make up for it. BOINC WIKI BOINCing since 2002/12/8 |
Send message Joined: 3 Apr 06 Posts: 547 |
4. Additional Buffer / Cache setting is 4.5 days OK, the buffer does not seem to be loaded. With 4 cores, I think it should be filled with 4.5*4=18 days of work. Another question is why the overworked project. Possibly others have no work? I think there is some cc_config debug flag (is it <work_fetch_debug>?), Boinc then explain its decision as which project is not contactable, which has no work and why actually this particular one was chosen. You could try this. Why am i getting this work when reportedly they are over-committed and overworked. Why is the cache seemingly impacting the priority processing when a permanent connection is present and scheduled to flush whatever is done on an hourly basis and all buffered work has real deadline dates of 7 and higher, but this 2nd problem project having 4? Remains unanswered :-( Peter |
Send message Joined: 29 Aug 05 Posts: 15480 |
Which project is so far in the plus, both on STD and LTD? Can that project fetch work? Does that project have work? |
Send message Joined: 3 Apr 06 Posts: 547 |
Peter, see line below point 7. BV says 20 days i.e equates to 5 days, but in practice it is done under 4 days on this 24/7 machine. Sekerob, I suppose these 20 days are shown on the Hosts tab, Work buffer (excuse me if I tell inexact names for tabs etc., I'm trying to guess english terms while looking at localized BoincView). You should take this value with a huge grain of salt. I've no idea what it does exactly mean, it is some average weighted time the work would last taking resource shares into account etc..... (Amanheis has been trying to explain it, but not many understod or liked it :) Sort of like the Work buffer values on the Projects tab are skewed. My examples: - My Linux 1-core host shows 6 days averaged sum on Proj tab, 19.8 days on Hosts tab and 6.9 days on Tasks tab, connect+add.cache are 0.5+1 days. It is a slooow P3 and there is a bit more work, because one Seti beta task is assumed to take 6.5 day. - My Wind. 2-core host: 6 days, 34.1 days, 12 days, connect every 8 days (I'll be off-line for a week). IMHO there is still not enough work cached (should be 16 days), but some projects with positive LTDs are ignoring the connect interval, sending work with shorter deadlines, which are immediately worked under EDF and i think the Client then can't download work from lower-LTD-projects. OTOH you can trust the bottom sum of the To completion values on the Tasks tab, this is a simple sum of the approximated times. As you say, "in practice it is done under 4 days". Is there a particular tilt point where LTD/STD negative values stop fetching? Quoting JM7 from mind, it should be LTD < -2*(Switch between applications every... seconds) But it is possibly ignored if really no other work is available. (But please don't quote me on this.) I have no more ideas to other questions so far. Ask Jord ;-) Peter [edited] |
Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.