Posts by Elektra*

Info	Message
1) Message boards : Android : Way to set CPU utilization? Message 63094 Posted 17 Jul 2015 by Elektra*	Permanent task switching between running and suspended may be a hint that the battery is nearly empty although charging it. That causes all tasks to suspend when the remaining battery power falls under a certain threshold and resume when power rises while the device being idle. My octa core smartphones have been supplied with way too weak chargers (max. 1A charging current). You need to feed your smarties with powerful chargers with at least 2A output. Samsung has a good charger as accessory with stable 2.1A output. Or you have a look at Amazon, they have some USB chargers with 5 or even 7 USB ports each driven with 2.5A. Sometimes it helps to remove the USB cable and reconnect it or even restart the device. Power supply and battery temperature are the most crucial weak points for power crunching with Android devices. I'd to see at two of my smartphones which are exclusively BOINCing the rear blowing away with a bang because the batteries blew up by overheating. Ok, a prick with a pin cured, and these devices are crunching again without further interference. Btw.: When using NativeBOINC and using global preferences (set by BOINCstats), maximal battery temperature is set to 300°C!!!! Way too much, 60°C should be the highest threshold, better 45°C. Especially during heat periods as currently in Germany your Androids get in troubles because of insufficient heat dissipation.
2) Message boards : Questions and problems : Why project schedule priority so high? Message 63044 Posted 14 Jul 2015 by Elektra*	The whitepaper for that is https://boinc.berkeley.edu/trac/wiki/ClientSchedOctTen. Proposal: credit-driven scheduling The idea is to make resource share apply to overall credit, not to individual resources types. If two projects have the same resource share, they should have the same RAC. Scheduling decisions should give preference to projects whose share of RAC is less than their resource share. There are problems with using project-granted credit as a basis for this approach: There may be a long and variable delay between completing a job and getting credit for it. Jobs may fail to get credit, e.g. because they don't validate. Hence we will use a surrogate called estimated credit, maintained by the client. If projects grant credit fairly, and if all jobs validate, then estimated credit is roughly equal to granted credit over the long term. And that's what the current BOINC v7 clients do. Because REC estimates credit much more closely in alignment with the formal definition of the cobblestone than many projects do, REC (and consequently Resource Share) follow flopcounting much more closely than they follow actual granted credit. I personally suspect that the 'flops' which are 'counted' for REC are those declared by the programmer/deployment administrator in <rsc_fpops_est>. That's my theory (partly) for why SETI's MB and AP tasks award different RAC, and likewise Albert's Arecibo and Perseus Arm surveys (IIRC those were the two apps which trended to different limit values). Richard mentioned the whitepaper which says how CreditNew should work, and here's another document that shows why CreditNew doesn't work at present and even won't work in the future: https://wiki.atlas.aei.uni-hannover.de/foswiki/bin/view/EinsteinAtHome/BOINC/EvaluationOfCreditNew The crunchpoint is the <dont_use_dcf> tag that many projects use. With my BOINC 6 clients I've reverted to, this tag is no problem as BOINC 6 doesn't know it, and the clients adjust themselves reliably with DCF. But with <dont_use_dcf> the newer clients ain't able to adjust themselves. They are able to see that the actual runtime of a task is diverging from the preempted runtime and then correct the supposed remaining time of this running task according to its progress, but the client will never adjust the preempted runtimes of the tasks in the buffer ready to start. So the Boinc clients of us volunteers are dependant on the project schedulers and their runtime estimates of the tasks they send. And the projects often badly underestimate the lengths of the tasks they send, and ain't able to adjust to the client sided conditions. There are some hints that some projects do this intentionally to gather higher shares (ressource theft). For me a drawback to BOINC 6 solved my problems, but that might be not an option for you as I'm only crunching CPU tasks.
3) Message boards : BOINC client : BOINC 7 development discussion thread. Message 59274 Posted 3 Jan 2015 by Elektra*	Small bug in 7.4.36: Jobs running at high priority are listed in the status column of the BOINC manager only as <running> but not as <running, high priority> like in older versions. I've verified that these jobs are still running with high priority after update 7.0.64 -> 7.4.36 (BoincTasks)
4) Message boards : BOINC client : BOINC 7 development discussion thread. Message 57596 Posted 12 Nov 2014 by Elektra*	The issue regarding a wrong URL for iGEM@home is known at BoincStats but without harm for the BOINC client resp. the scheduler. I've removed the <no new tasks> setting for WCG and I am currently running another test. I'll post the results and log files per eMail to the developer group to avoid an overrunning of this thread with endless debug logs. But the error remains the same: BOINC client 7.4.27 isn't able to replace finished tasks with tasks from running backup projects (resource share = 0) when the only main project (resource share = 100) is out of work, and in the end all CPU cores are without work from BOINC.
5) Message boards : BOINC client : BOINC 7 development discussion thread. Message 57536 Posted 11 Nov 2014 by Elektra*	Probably a bug in 7.4.27: At present I'm running skynetPOGS and WU-Prop with resource share 100 and WCG as backup project with resource share 0 As POGS doesn't send new tasks at present, WCG should provide my CPU's with work. No problems with 7.2.42, BOINC client asked WCG properly for work each time a task was finished. When updating to 7.4.27, BOINC client messaged "no tasks needed" (WCG) and only WUprop was running on one core. Reverting back to 7.2.42 all cores were immediately provided with sufficient tasks from the backup project.
6) Message boards : The Lounge : Word Link Message 54939 Posted 18 Jul 2014 by Elektra*	Empire

Copyright © 2025 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.