I already reported it in "Technical News" (message 198154), but maybe this wasn't the right place, so I post it here again.
The issue is that the "v1.61 aarch64-unknown-linux-gnu" application does seem to not validate against Android in some cases at least. Most recent of my WUs: 662042694, not sure if related, but again both aarch64 machines have BCM2835 CPU.
It's like with Intel GPUs in the past, if the 3rd result goes to an Android device, the Androids win, if it goes to an aarch64 maschine (whatever that is), they win.
I already reported it in "Technical News" (message 198154), but maybe this wasn't the right place, so I post it here again.
The issue is that the "v1.61 aarch64-unknown-linux-gnu" application does seem to not validate against Android in some cases at least. Most recent of my WUs: 662042694, not sure if related, but again both aarch64 machines have BCM2835 CPU.
It's like with Intel GPUs in the past, if the 3rd result goes to an Android device, the Androids win, if it goes to an aarch64 maschine (whatever that is), they win.
Some updates from me on this issue...
Since the invalid rate increased to an insane level for me (20+%), I wrote my own app_info and moved that host to BRP4G, where it's safe from Intel GPUs and aarch. Completed 5 WUs until now (equals 40 BRP4 WUs), they all validated against the results from CPU apps without any issues, no inconclusives, no invalids. So as far as I can tell, both the einsteinbinary_BRP4_1.43_arm-android-linux-gnu__NEON and my device seem to be absolutely OK, not sure about the Intel GPU and aarch apps. If their results are good enough, than there's something wrong with the validator, but I guess the results of those apps often won't validate against x86-CPU results like they don't against the Android results.
No idea why, but somehow the device needs about 800-1000 seconds (~2%) less per BRP4 WU, that increases the efficiency even more for me.
EXIT_TIME_LIMIT_EXCEEDED means the task has run a lot slower than BOINC has expect it to run. When looking at the details of that host, I see insane measured speed values, that's the cause. Rerun benchmarks, if that doesn't change them to something more realistic, change them manually in client_state.xml to 1/100th of the current values and disable benchmarks in cc_config.xml, DCF will do the fine tuning.
I keep getting computation error on the android app and only for this project. I tried reloading the project but does the same. how can I pull the logs you need or any ideas for a fix?
Thanks for the report. You don't need to pull any logs since you're already providing them via your account. We're going to look into it, hopefully next week. Please have some patience, though, as we're currently understaffed.
I already reported it in
)
I already reported it in "Technical News" (message 198154), but maybe this wasn't the right place, so I post it here again.
The issue is that the "v1.61 aarch64-unknown-linux-gnu" application does seem to not validate against Android in some cases at least. Most recent of my WUs: 662042694, not sure if related, but again both aarch64 machines have BCM2835 CPU.
It's like with Intel GPUs in the past, if the 3rd result goes to an Android device, the Androids win, if it goes to an aarch64 maschine (whatever that is), they win.
.
Thanks for the report. We'll
)
Thanks for the report. We'll look into it. Word of caution: we're a bit tight on resources at the moment, so it might take some time.
Cheers!
Einstein@Home Project
We're actively exploring some
)
We're actively exploring some of this in a different Technical News thread. See message 199770.
Not sure if it helps you, but
)
Not sure if it helps you, but the aarch app seem to validate against Intel GPUs, this is the 2nd time I see it: WU 663350814.
.
Link wrote:I already reported
)
Some updates from me on this issue...
Since the invalid rate increased to an insane level for me (20+%), I wrote my own app_info and moved that host to BRP4G, where it's safe from Intel GPUs and aarch. Completed 5 WUs until now (equals 40 BRP4 WUs), they all validated against the results from CPU apps without any issues, no inconclusives, no invalids. So as far as I can tell, both the einsteinbinary_BRP4_1.43_arm-android-linux-gnu__NEON and my device seem to be absolutely OK, not sure about the Intel GPU and aarch apps. If their results are good enough, than there's something wrong with the validator, but I guess the results of those apps often won't validate against x86-CPU results like they don't against the Android results.
No idea why, but somehow the device needs about 800-1000 seconds (~2%) less per BRP4 WU, that increases the efficiency even more for me.
.
Is there any issue
)
Is there any issue with ASIMDPIE_1X? I am getting tons of "Error while computing" status:
Server state: Over
Outcome: Computation error
Client state: Compute error
Exit status: 197 (0x000000C5) EXIT_TIME_LIMIT_EXCEEDED
Example: https://einsteinathome.org/task/1400175732
Checking strace shows there's SIGALRM signal
EXIT_TIME_LIMIT_EXCEEDED
)
EXIT_TIME_LIMIT_EXCEEDED means the task has run a lot slower than BOINC has expect it to run. When looking at the details of that host, I see insane measured speed values, that's the cause. Rerun benchmarks, if that doesn't change them to something more realistic, change them manually in client_state.xml to 1/100th of the current values and disable benchmarks in cc_config.xml, DCF will do the fine tuning.
.
I keep getting computation
)
I keep getting computation error on the android app and only for this project. I tried reloading the project but does the same. how can I pull the logs you need or any ideas for a fix?
Running on samsung S24 ultra
Boinc version 7.24.1 (292704f771)
Thanks for the report. You
)
Thanks for the report. You don't need to pull any logs since you're already providing them via your account. We're going to look into it, hopefully next week. Please have some patience, though, as we're currently understaffed.
Cheers,
Oliver
Einstein@Home Project
I'm having the exact same
)
I'm having the exact same issue on my S24 Plus, i think it may be an issue with the 24 series Samsung phones specifically.