Android app release: feedback thread

Link
Link
Joined: 15 Mar 20
Posts: 96
Credit: 563,569
RAC: 125

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.

.

Oliver Behnke
Oliver Behnke
Moderator
Administrator
Joined: 4 Sep 07
Posts: 935
Credit: 25,166,626
RAC: 0

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

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 2,139
Credit: 2,717,559,530
RAC: 1,404,857

We're actively exploring some

We're actively exploring some of this in a different Technical News thread. See message 199770.

Link
Link
Joined: 15 Mar 20
Posts: 96
Credit: 563,569
RAC: 125

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
Link
Joined: 15 Mar 20
Posts: 96
Credit: 563,569
RAC: 125

Link wrote:I already reported

Link wrote:

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.

.

Jia Yuan Lo
Jia Yuan Lo
Joined: 30 May 22
Posts: 1
Credit: 24,563
RAC: 0

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

Link
Link
Joined: 15 Mar 20
Posts: 96
Credit: 563,569
RAC: 125

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.

.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.