Yeah in fact the Android 10 seems more stable than the 9 with my devices. But my Android 9 phone is behaving weirdly anyway so it might be itself the reason of these errors but préfères to warn about it
I found a definition that it has 4 large and 4 small cores.
Yep, that should be the reason for it.
Quote:
Perhaps just a increase of the runtime limit will fix the problem. (more then double or even 3 times the current runtime limit)
Honestly, I doubt we can do that as it would probably "confuse" BOINC's internal runtime estimations. I would recommend to use (the) four (large) cores only. In the end it's also matter of efficiency and the small cores aren't tailored towards that kind of usage.
Oliver, thanks for confirming that the Octacore design is the problem.
But I think there is a misunderstanding about the parameter setting.
I would like to see a higher value for the parameter: rsc_fpops_bound. This is the kill switch that aborts bad workunits that run forever but now it is killing good workunits that just run very slow.
Runtime estimates are defined in parameter: rsc_fpops_est. I don't want any change to that.
Good point. Unfortunately, it's not that easy due to technical constraints wihtin BOINC. We're currently running that app not only on relatively slow Android devices but also on relatively fast Intel GPUs. So far we could strike a balance between those performance domains, with rsc_fpops_bound errors in only < 5% of all tasks. Tailoring things toward a specific platform would make setting runtime constraints easier but would in turn lead to disadvantages in scientific result validation across platforms - it's a trade-off.
As you can see, we always have to find the optimal balance/compromise within the limitations BOINC still has.
We'll look into our options again to see if we find can improve things.
Just noticed a different problem. I have a Samsung tablet (host 12858658), which has been pottering along running the 'Binary Radio Pulsar Search (Arecibo) v1.46 (NEONPIE)' app sub-version.
Until 26 Feb 2021 17:05:07 UTC, when the server started sending it the (VFP) sub-version. Since then, all tasks have failed with
error: Android 5.0 and later only support position-independent executables (-fPIE).
Hi everyone. I am trying to set up a Galaxy S9 with Android 10 to run Einstein but it doesn't receive any work. In my personal settings I have accepted all projects except the ones that offer GPU support. Did I miss a key setting somewhere or are there just no WU's available?
Yeah in fact the Android 10
)
Yeah in fact the Android 10 seems more stable than the 9 with my devices. But my Android 9 phone is behaving weirdly anyway so it might be itself the reason of these errors but préfères to warn about it
I have also had the time
)
I have also had the time exceed problem. I run on a tablet with a Octa-core chip and Android 10.
I found that if I set Boinc to use all 8 cores that the problem occurs but if I use only 4 cores ,no problems.
The cause of the problem may be the design of the Octa-core. I found a definition that it has 4 large and 4 small cores.
By running 8 cores it becomes much slower and that may be the cause for the timelimit overrun.
Perhaps just a increase of the runtime limit will fix the problem. (more then double or even 3 times the current runtime limit)
Henk Haneveld wrote:I found
)
Yep, that should be the reason for it.
Honestly, I doubt we can do that as it would probably "confuse" BOINC's internal runtime estimations. I would recommend to use (the) four (large) cores only. In the end it's also matter of efficiency and the small cores aren't tailored towards that kind of usage.
Oliver
Einstein@Home Project
Oliver, thanks for confirming
)
Oliver, thanks for confirming that the Octacore design is the problem.
But I think there is a misunderstanding about the parameter setting.
I would like to see a higher value for the parameter: rsc_fpops_bound. This is the kill switch that aborts bad workunits that run forever but now it is killing good workunits that just run very slow.
Runtime estimates are defined in parameter: rsc_fpops_est. I don't want any change to that.
Good point. Unfortunately,
)
Good point. Unfortunately, it's not that easy due to technical constraints wihtin BOINC. We're currently running that app not only on relatively slow Android devices but also on relatively fast Intel GPUs. So far we could strike a balance between those performance domains, with rsc_fpops_bound errors in only < 5% of all tasks. Tailoring things toward a specific platform would make setting runtime constraints easier but would in turn lead to disadvantages in scientific result validation across platforms - it's a trade-off.
As you can see, we always have to find the optimal balance/compromise within the limitations BOINC still has.
We'll look into our options again to see if we find can improve things.
Oliver
Einstein@Home Project
Just noticed a different
)
Just noticed a different problem. I have a Samsung tablet (host 12858658), which has been pottering along running the 'Binary Radio Pulsar Search (Arecibo) v1.46 (NEONPIE)' app sub-version.
Until 26 Feb 2021 17:05:07 UTC, when the server started sending it the (VFP) sub-version. Since then, all tasks have failed with
Your problem or mine?
Duh, mine! Plan class
)
Duh, mine! Plan class intricacies once again. We just have too many... Fixed!
Mea culpa,
Oliver
Einstein@Home Project
Oliver Behnke wrote: Duh,
)
Thanks - I'll check in the morning. (I'm in a quota black hole until midnight...)
Happy to report that my
)
Happy to report that my tablet is breakfasting on its normal diet of NEONPIE. Problem over.
Hi everyone. I am trying to
)
Hi everyone. I am trying to set up a Galaxy S9 with Android 10 to run Einstein but it doesn't receive any work. In my personal settings I have accepted all projects except the ones that offer GPU support. Did I miss a key setting somewhere or are there just no WU's available?