I think he meant to say, "Perhaps a change is needed so that Android 10 devices stop being blocked." I don't know anything about Android stuff but perhaps the scheduler blocks certain versions, eg. above 9?
Not as far as I can see. We have some special handling of older Android 4.x devices but that's it, I think. Thus I'd really need to see the details to be able to help.
His computers aren't hidden so I decided to take a look. I found this one that mentions Android 10 and so I clicked on the last scheduler contact link for it. The following snippet seems to indicate his problem.
2020-04-15 22:43:21.3209 [PID=23442] [version] CPU [' fp asimd evtstrm aes pmull sha1 sha2 crc32 impl 0x51 arch 8 variant 0xa part 0x801 rev 4 '] lacks feature ' neon '
2020-04-15 22:43:21.3209 [PID=23442] [version] Checking plan class 'VFP'
2020-04-15 22:43:21.3209 [PID=23442] [version] CPU [' fp asimd evtstrm aes pmull sha1 sha2 crc32 impl 0x51 arch 8 variant 0xa part 0x801 rev 4 '] lacks feature ' vfp '
2020-04-15 22:43:21.3210 [PID=23442] [version] Checking plan class 'ASIMDPIE'
2020-04-15 22:43:21.3210 [PID=23442] [version] Couldn't match OS version '4.4.210-perf+ (Android 10)' with required regexp 'Android [987N65]|Android 4\.[1-9]|3\.4\.[0-9]'
2020-04-15 22:43:21.3210 [PID=23442] [version] Checking plan class 'NEONPIE'
2020-04-15 22:43:21.3210 [PID=23442] [version] CPU [' fp asimd evtstrm aes pmull sha1 sha2 crc32 impl 0x51 arch 8 variant 0xa part 0x801 rev 4 '] lacks feature ' neon '
One of those (plan class 'ASIMDPIE') shows an Android 10 test failing to match the regexp. Maybe that's what he was referring to? I've no clue about those class names so hopefully that helps.
Cheers,
Gary.
EDIT: I just noticed more devices, lower down in his list (older last contact dates) that are also listed as Android 10. They seem to have exactly the same regex failure.
Thanks. My bad, I confused the kernel version with the Android version. You were right, we lacked support for Android 1X which I now added. Please give it a try...
Sorry so late in following up on the posts. You folks solved it! Thank you so much for the investigative effort! I really appreciate the Android 10 support!
Hm, this seems to be client-related problem to me. An error "Maximum disk usage exceeded" while the task's "Peak disk usage" is 20.04 MB doesn't indicate an app or task problem to me. Please check your client's disk limit setting and/or the number of tasks currently assigned (not just running) to that client.
Hm, this seems to be client-related problem to me. An error "Maximum disk usage exceeded" while the task's "Peak disk usage" is 20.04 MB doesn't indicate an app or task problem to me. Please check your client's disk limit setting and/or the number of tasks currently assigned (not just running) to that client.
Oliver
BOINC configured to use 90% (max for Android client), left 0.1GB free (mn for Android client, would like to make it less, but can't). E@h configured as backup project so always no more than number of cores (4 tasks for 4 cores there).
So it looks like it attempts to run so many tasks that it can't handle none of them. Host downloads new tasks and errors them out regularly.
Better behavior would be to prevent starting new tasks if currently running fill the storage - that would allow at least some CPU cores do smth good instead of just waste bandwidth and energy. But indeed then it's BOINC client issue, not project app one.
For the sake of experiment I'll reduce number of CPU cores to 1 on that host for few days and see if it can handle E@h work at all.
You're right an all aspects. However, you didn't say anything about the actual free disk space. If that approaches the 100 MB you set then four tasks (for four cores) would already be close to, if not exceeding, the limit.
Another idea: there's a setting that allows to influence the client's task cache. This controls who many tasks are downloaded (cached) before they're run. If you reduce that cache size it will obviously reduce the disk limit pressure. Thus it's important to keep this two settings well aligned - unfortunately I just can remember right now how that cache setting is called... Duh!
Hi Oliver, thanks for looking
)
Hi Oliver, thanks for looking into this.
I think he meant to say, "Perhaps a change is needed so that Android 10 devices stop being blocked." I don't know anything about Android stuff but perhaps the scheduler blocks certain versions, eg. above 9?
Cheers,
Gary.
Not as far as I can see. We
)
Not as far as I can see. We have some special handling of older Android 4.x devices but that's it, I think. Thus I'd really need to see the details to be able to help.
Cheers,
Oliver
Einstein@Home Project
His computers aren't hidden
)
His computers aren't hidden so I decided to take a look. I found this one that mentions Android 10 and so I clicked on the last scheduler contact link for it. The following snippet seems to indicate his problem.
2020-04-15 22:43:21.3209 [PID=23442] [version] CPU [' fp asimd evtstrm aes pmull sha1 sha2 crc32 impl 0x51 arch 8 variant 0xa part 0x801 rev 4 '] lacks feature ' neon ' 2020-04-15 22:43:21.3209 [PID=23442] [version] Checking plan class 'VFP' 2020-04-15 22:43:21.3209 [PID=23442] [version] CPU [' fp asimd evtstrm aes pmull sha1 sha2 crc32 impl 0x51 arch 8 variant 0xa part 0x801 rev 4 '] lacks feature ' vfp ' 2020-04-15 22:43:21.3210 [PID=23442] [version] Checking plan class 'ASIMDPIE' 2020-04-15 22:43:21.3210 [PID=23442] [version] Couldn't match OS version '4.4.210-perf+ (Android 10)' with required regexp 'Android [987N65]|Android 4\.[1-9]|3\.4\.[0-9]' 2020-04-15 22:43:21.3210 [PID=23442] [version] Checking plan class 'NEONPIE' 2020-04-15 22:43:21.3210 [PID=23442] [version] CPU [' fp asimd evtstrm aes pmull sha1 sha2 crc32 impl 0x51 arch 8 variant 0xa part 0x801 rev 4 '] lacks feature ' neon 'One of those (plan class 'ASIMDPIE') shows an Android 10 test failing to match the regexp. Maybe that's what he was referring to? I've no clue about those class names so hopefully that helps.
Cheers,
Gary.
EDIT: I just noticed more devices, lower down in his list (older last contact dates) that are also listed as Android 10. They seem to have exactly the same regex failure.
Cheers,
Gary.
Thanks. My bad, I confused
)
Thanks. My bad, I confused the kernel version with the Android version. You were right, we lacked support for Android 1X which I now added. Please give it a try...
Oliver
Einstein@Home Project
Sorry so late in following up
)
Sorry so late in following up on the posts. You folks solved it! Thank you so much for the investigative effort! I really appreciate the Android 10 support!
You're most welcome! I'm
)
You're most welcome! I'm glad it was sorted for you.
Cheers,
Gary.
https://einsteinathome.org/ru
)
https://einsteinathome.org/ru/task/942986989
arm-android-linux-gnu
Hm, this seems to be
)
Hm, this seems to be client-related problem to me. An error "Maximum disk usage exceeded" while the task's "Peak disk usage" is 20.04 MB doesn't indicate an app or task problem to me. Please check your client's disk limit setting and/or the number of tasks currently assigned (not just running) to that client.
Oliver
Einstein@Home Project
Oliver Behnke написал:Hm,
)
BOINC configured to use 90% (max for Android client), left 0.1GB free (mn for Android client, would like to make it less, but can't). E@h configured as backup project so always no more than number of cores (4 tasks for 4 cores there).
So it looks like it attempts to run so many tasks that it can't handle none of them. Host downloads new tasks and errors them out regularly.
Better behavior would be to prevent starting new tasks if currently running fill the storage - that would allow at least some CPU cores do smth good instead of just waste bandwidth and energy. But indeed then it's BOINC client issue, not project app one.
For the sake of experiment I'll reduce number of CPU cores to 1 on that host for few days and see if it can handle E@h work at all.
You're right an all aspects.
)
You're right an all aspects. However, you didn't say anything about the actual free disk space. If that approaches the 100 MB you set then four tasks (for four cores) would already be close to, if not exceeding, the limit.
Another idea: there's a setting that allows to influence the client's task cache. This controls who many tasks are downloaded (cached) before they're run. If you reduce that cache size it will obviously reduce the disk limit pressure. Thus it's important to keep this two settings well aligned - unfortunately I just can remember right now how that cache setting is called... Duh!
Oliver
Einstein@Home Project