Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
![]() |
World Community Grid Forums
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
No member browsing this thread |
Thread Status: Active Total posts in this thread: 11
|
![]() |
Author |
|
Pilot_51
Cruncher Joined: Sep 20, 2017 Post Count: 5 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
I've noticed a strange and kind of annoying issue on the website where Android results don't stick around very long at all. I had one task that was running a few days past the deadline, appearing as "No Reply" in results, and should have completed last night. However, when I checked today, the result was gone. I even left the WU status page open in a tab so I could just refresh it and see what the result was, thinking it was only disappearing from the results on my profile. It appears that upon completion of my late task, all results for the WU completely disappeared.
----------------------------------------I haven't noticed this issue with PC results, though PC is also much less likely to complete tasks late. Not sure if this is an issue specifically with Android results or just that Android makes a larger issue more obvious by frequently returning results late. This, as well as some other issues that make the BOINC app kind of frustrating to use, is pushing me to stop contributing with my Android phone. It only accounts for about 0.3% of my points generated, anyway. [Edit 1 times, last edit by Pilot_51 at Nov 16, 2017 7:41:27 PM] |
||
|
SekeRob
Master Cruncher Joined: Jan 7, 2013 Post Count: 2741 Status: Offline |
Snip
I had one task that was running a few days past the deadline, appearing as "No Reply" in results, and should have completed last night. Practically immediately upon No Reply a copy is sent to another machine. UIf that is quickly processed, it having a short deadline, then there's about 24 hours that the validated result will stay on, after which all get transited to the master database and removed from the result status page. If your copy got returned later, then your result will actually turn 'no longer usable in the BOINC event log, and your result goes straight to the round archive, so fear that is what happened to your over-overdue result. |
||
|
Pilot_51
Cruncher Joined: Sep 20, 2017 Post Count: 5 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
One of my problems with the BOINC app on Android is that the event log is pretty much useless. Nearly every time I look at it, it only shows setup messages usually timestamped about an hour earlier. In this most recent case, I'm certain the client was running the entire night up until I checked around noon after the task was gone, yet there were no messages about the task in the log, it only showed setup messages timestamped just over an hour earlier. Though, one of those setup messages was warning me of another late task that might not get credit, which has been running at 100% completed for at least 6 hours (inaccurate task progress is another issue I have with the Android app).
I understand what you're saying about the 24 hour thing, and makes sense now that I look at the WU status for my PC results. It seems the reason my PC results stick around so much longer (up to about 2 weeks after completion) is because they require a quorum of at least 2 and at least one other client isn't returning a result in a timely manner, usually missing their deadline. My Android device, on the other hand, tends to be the slow one, so the results are gone within 24 hours of completion if not before completion because it was way late. While yes, quickly moving the results to the master database makes sense, I would still like a decent opportunity to confirm the final status for my recent returned results and easily spot negative trends (such as certain projects with a deadline often too short to complete in time on the device) without having to check the results page every day. If reading back from the master database isn't a reasonable option, I'm thinking something like a snapshot of the result that was sent to the master database, which could have its own longer expiration or perhaps even go to a separate archive section if it's not too heavy on server resources. Anyway, thanks for clearing this up. I was almost convinced I was experiencing a bug. |
||
|
adriverhoef
Master Cruncher The Netherlands Joined: Apr 3, 2009 Post Count: 2156 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Pilot_51, I'm just wondering why you're passing the deadline, trying to help you make any sensible decisions. My Android device runs 1 job at a time, while having at most 3 jobs in the queue, and it usually takes 12 hours for 1 job to complete, so it should never be too late handing back any results.
![]() |
||
|
Pilot_51
Cruncher Joined: Sep 20, 2017 Post Count: 5 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
I have a Nexus 5X with 6 cores (4x 1.4GHz + 2x 1.8GHz) and was running 3 tasks at a time. I had it configured to only run with battery over 90% and temp below 40C, even unplugged. I've selected projects that typically have jobs taking less than an hour on my main PC so my phone isn't stuck with really large tasks. The side effect seems to be a much shorter deadline, usually somewhere between 24 hours and 2 weeks. On my phone, most tasks tend to take about 40 hours of processing time to complete. I also noticed that when a task is suspended and resumed, as is very common on the phone, the progress sometimes jumps back quite a bit, from about 20% to 0% in one recent case.
|
||
|
adriverhoef
Master Cruncher The Netherlands Joined: Apr 3, 2009 Post Count: 2156 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
On my Android phone, when I run 2 jobs instead of one, the runtime of both jobs will be doubled, and when I run 4 jobs instead of one, the runtime of all 4 jobs will be four times that of 1 job. So what I did was to reduce the number of running jobs to 1. Furthermore, I didn't like some of the huge gaps between checkpoints, so I switched to a project with small gaps between checkpoints: ZIKA. Now I'm not saying that you should do as I did, it's just an idea.
![]() Maybe you could do some experimenting. |
||
|
Pilot_51
Cruncher Joined: Sep 20, 2017 Post Count: 5 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
That seems to be the trick. Much faster when running 1 task at a time. That suggests the app may not be utilizing the CPU cores correctly for multiple tasks. This is satisfactory, I don't feel like giving up on it any more.
I think I should have submitted this thread to the Android Support Forum instead of Website Support. Mods, feel free to move it there. |
||
|
ErikaT
Former World Community Grid Admin USA Joined: Apr 27, 2009 Post Count: 912 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
This thread is being moved to the Android Support thread.
ErikaT |
||
|
SekeRob
Master Cruncher Joined: Jan 7, 2013 Post Count: 2741 Status: Offline |
On my Android phone, when I run 2 jobs instead of one, the runtime of both jobs will be doubled, and when I run 4 jobs instead of one, the runtime of all 4 jobs will be four times that of 1 job. So what I did was to reduce the number of running jobs to 1. Furthermore, I didn't like some of the huge gaps between checkpoints, so I switched to a project with small gaps between checkpoints: ZIKA. Now I'm not saying that you should do as I did, it's just an idea. ![]() Maybe you could do some experimenting. Most puzzling observation, so decided to run my 4 core Nexus, which I always run at 2 for BOINC, as 1 threaded OET1 only and find at 2 threads the mean was 5.04 CPU hours, elapsed 5.13 (98.3% efficiency), and just running 1 thread 5.09 CPU hours, elapsed 5.21 (97.7% efficiency), sample size 10. Suppose there's apples and oranges amongst ARM CPU's. |
||
|
supdood
Senior Cruncher USA Joined: Aug 6, 2015 Post Count: 333 Status: Offline Project Badges: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Pilot,
----------------------------------------Based on the characteristics you described, it sounds like a lot of your problems are due to the OET1 project and the way you are using your android to crunch, not with your device setup. The OET1 project only checkpoints every 12.5%, and if you suspend for any reason (user, battery, heat) you will lose a lot of progress. It also takes a while to make the finishing calculations while showing 100%, and again you will lose progress if you suspend. One area of concern is why it is taking 40 hours to complete a WU. I haven't had an android on OET1 for a while, but this seems like it is way too long. I would recommend switching to SCC1 if you are going to actively use your phone. I've found this to be the most stable for crunching on an active device (no checkpoint issues like OET1 and much reduced RAM/segmentation violation issues like ZIKA). Hope this helps make your WCG experience more enjoyable. ---------------------------------------- [Edit 1 times, last edit by supdood at Nov 28, 2017 6:25:22 PM] |
||
|
|
![]() |