How big is your cache?

Did you run the benchmark? What are the deadlines? What client [exact] version?


edit: And of course the system clock... what's time time/date? Else, with 1 day cache, just let it run and it will right, at some point in time.

--//--

running benchmark and rebooting...
the uptime on my boxen gets very high...

A 1 day cache setting will keep 1 day, no matter if 1 project or 10 active are attached. The buffer split is broadly speaking as per the resource share / project weight setting.

--//--

Bugg, what you're on about... no, not correct! 10.53% the duration would have increased against a new benchmark for the *total* buffer which the client maintains at 1.0 day setting, *not* a by-attached-project. There's no logic why the HP state developed, but the client to think that there is not enough time left. If one of these undisclosed tricks are set such as 6000 minutes switch time to push the beta ahead, that would also apply to repair jobs... did ask about the deadlines, but the answer was not given, so we put a wet finger in the air to find the wind direction. There could have been a coincidental task that was estimated at 5 minutes that suddenly ran 60 minutes [an HCMD2], and that could have send the DCF up the famous creek. By the time Ron wakes up the HP state will have likely self-dissolved.

BTW, not downloading work because the buffer went above the 1 day setting by itself and maintaining default would *not* have set the HP state off. It's deadlines and what the client thinks it can do in the allotted time with the work that is already on the device and whatever other [forgotten] setting was changed in BOINC. 400Mhz downclocking is absolutely no explanation.

--//--