Greetings,

I have a LENOVO IdeaTab S6000-F - SDK:17 ABI: armeabi-v7a tablet running on Android 3.4.5 (Android 4.2.2) with a ARMv7 Processor rev 2 (v7l) (4 processors) CPU. Its Run time and CPU time are out of range of each other, roughly Run time double the CPU time. I'll link to the finished WUs but no guarantee they'll stay for very long. They tend to leave the page quickly.

WU 1: Waiting for validation
WU 2: Validated
WU 3: Validated

I'm not sure how to get the Run times and CPU times in line with each other. Any help would be greatly appreciated. :)

Have a great day! :)

Siran

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

The three results you provide links to are evidence that the CPU on that computer is over committed, and is thus having to "slice" time between different jobs.
I'm not sure how Android manages this sort of thing, but on Windows & Linux reducing the fraction of the total number of CPUs in use by 1 core will often cure this problem (and result in a larger overall throughput of work). In the case of your Android device it would appear to have 4 cores, so set the "use at most % CPU cores" to 75%.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

The three results you provide links to are evidence that the CPU on that computer is over committed, and is thus having to "slice" time between different jobs.
I'm not sure how Android manages this sort of thing, but on Windows & Linux reducing the fraction of the total number of CPUs in use by 1 core will often cure this problem (and result in a larger overall throughput of work). In the case of your Android device it would appear to have 4 cores, so set the "use at most % CPU cores" to 75%.

Hi Rob,

Thanks, I'll give that a try and see what happens.

Have a great day! :)

Siran

[edit]
I made the change. The values are in increments of 10 so I have it set at 70%. I noticed that the running tasks cycle between running and suspended if lower than 100%. I'll see how this works out for the tablet. :)
[/edit]

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

Siran:

Rob is correct in why they are far apart.

CPU time is kept by the O/S in clock ticks. Run time is wall clock time kept by BOINC. No matter what the CPU time will be less than the run time because the O/S doesn't count the time that the program is in wait state while I/O is happening. If the times are close then you aren't over committed.

But a reason they can get far apart when over committed is lack of RAM. The O/S has to swap the program out of RAM then swap in different one to allow it to run. That hurts not only BOINC but every other job the computer is running. Another reason is real time tasks, such as playing video. In that case the video is a higher priority job and it steals the CPU from the BOINC job many times but for very short chunks. The O/S correctly logs only the clock time, but BOINC doesn't know the job wasn't running for all those small interrupts and they can add up quickly.

Gary

Siran:

Rob is correct in why they are far apart.

CPU time is kept by the O/S in clock ticks. Run time is wall clock time kept by BOINC. No matter what the CPU time will be less than the run time because the O/S doesn't count the time that the program is in wait state while I/O is happening. If the times are close then you aren't over committed.

But a reason they can get far apart when over committed is lack of RAM. The O/S has to swap the program out of RAM then swap in different one to allow it to run. That hurts not only BOINC but every other job the computer is running. Another reason is real time tasks, such as playing video. In that case the video is a higher priority job and it steals the CPU from the BOINC job many times but for very short chunks. The O/S correctly logs only the clock time, but BOINC doesn't know the job wasn't running for all those small interrupts and they can add up quickly.

Gary

Hi Gary,

Yeah, I haven't really been paying much attention to the way the tablet was running BOINC. I figured the source; It's a tablet. lol ;)

I already reduced the CPU usage to 70% and just now I reduced how many cores it uses. It was running 2 WUs at the same time. I thought it was only running 1. Goes to show just how long it's been since I looked at it. ;) So now 1 WU is being tackled while the other is waiting on the sidelines. Perhaps running only 1 at a time will also shorten the crunch time. :)

Thanks Gary and have a great day! :)

Siran

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

I already reduced the CPU usage to 70%

A difference between Run time & CPU time for CPU WUs will also occur when "Use at most 100 % of CPU time" is set to a value lower than 100%. The lower the value, the bigger the difference between CPU time & Run time will be.

---

Grant
Darwin NT

Try setting the CPU usage to 100%, but limiting the number of processors to 50 or 75%.

This limits the number of tasks to 2 or 3, and leaves a core free for other tasks. With all 4 cores in use the system has to keep swapping from Boinc to "whatever else needs doing", and that's very inefficient.

Although the BOINC tasks are "low priority" and the system can suspend them whenever it needs, they tend to use all the CPU cache memory. So now the higher priority task has to work from main RAM, which is slower meaning it takes longer to get back to the BOINC job, THEN, when the BOINC task takes over again, it's been flushed from the cache, and also takes longer to get running again. Then they swap back....

On a more powerful CPU with a heap more cache this is less noticeable, but on a little ARM chip, well you see the result.

But by running less tasks you A: Cut down on the need for swapping tasks, as there is a core or 2 free, and B: Allow the cache memory to work more efficiently, as there is less BOINC tasks to clog it up, and less "cache misses".

The % of CPU time just means the tasks get paused every X milliseconds, then resume again. Can cut down on the heat created, but all the cache issues and task swapping is still occurring, so it's the wrong setting for this scenario. If you set CPU time to 50% then the CPU time will end up at LEAST 2X the Run time, because the CPU was only allowed to work on it 1/2 the time.

Greetings,

@ Grant and Ianab:

I have reset the CPU usage back to 100%. Yesterday I reduced the number of WUs from 2 to 1 so I have one running and one waiting to run. Once the first one is done and the second one is back to crunching, I assume I'll start to see some better performance from that dinosaur tablet. I'm sure not a difference of a few seconds like my Winders and Linux PCs or my Pis and laptop, but some better performance nonetheless. Right? ;)

Have a great day! :)

Siran

---

CAPT Siran d'Vel'nahr - L L & P _\\//
Winders 11 OS? "What a piece of junk!" - L. Skywalker
"Logic is the cement of our civilization with which we ascend from chaos using reason as our guide." - T'Plana-hath

I assume I'll start to see some better performance from that dinosaur tablet.

The CPU time will remain unchanged (for a given WU), but the Runtime should come down to within a few minutes of the CPU time.

---

Grant
Darwin NT

if u can't set 75% try the app_config and feed only 3 cores

<app_config>
<app>
<name>setiathome_v8</name>
<max_concurrent>3</max_concurrent>
</app>
<app>
</app_config>

---