Closed Bug 1004300 Opened 6 years ago Closed 6 years ago

[B2G][Tarako][Email][Camera]Poor device performance attempting to launch email and add camera app photo as attachment with low battery

Categories

(Firefox OS Graveyard :: Performance, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:1.3T+, b2g-v1.3 unaffected, b2g-v1.3T affected)

RESOLVED WORKSFORME
2.0 S1 (9may)
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3 --- unaffected
b2g-v1.3T --- affected

People

(Reporter: mclemmons, Assigned: yiwen.liu)

References

()

Details

(Keywords: perf, Whiteboard: [tarako-exploratory][POVB][c=progress p= s= u=tarako])

User taps Email App for IMAP+SMTP account and attempts to add a camera photo as an attachment to a new email. With low battery – less than 25 percent, device performance is poor. The witnessed behavior was the email app loading slowly to a black screen, once the inbox appeared, tapping on new message was slow to react. When enabled and on the compose screen, selecting the attachment icon was slow to react. Afterward, the camera photo screen displayed but not able to take a photo unless a lengthy wait occurred. Sometimes, the photo taking button briefly disappeared with the blue halo in place then reappeared. When the device was plugged via USB cable and charging, performance significantly improved. Two other testers with Tarakos at above 50 percent charge followed the same STR and did not experience any inconsistent behavior. Video evidence provided.

Prerequisites: Manual setup of IMAP+SMTP account with a low battery (<25 percent)

Repro Steps:
1) Updated Tarako to BuildID: 20140429014002
2) Observe behavior closely while following step 3 and 4
3) Tap Email App
4) Tap New Message icon and select attachment icon then tap camera and take photo

Actual:
Random inconsistencies – Email App opens slowly, New message icon opens slowly, Attachment icon opens slowly, Camera taking icon reacts slowly and displays vanishing visuals  (1:10 mark of video) during process, before picture finally taken after over a minute.

Expected:
Apps open consistently without slow reactions and without vanishing visuals. 

Notes: 
Repro frequency: 3/3 – 100 percent with low battery 0/6 – 0 percent with greater than 50 percent battery

Video clip = https://www.youtube.com/watch?v=VfcX751mHzs
With firewatch and logcat using the device in charge mode, which doesn't reproduce behavior, these logs are not provided

The type of device in use – Tarako
The "Build Identifier" of the build you are using = 20140429024001 
Confirm the net connection is working – Yes Confirmed
The e-mail domain you used/are using to create the account – gmail.com 
If this is not a problem creating the account, the account type the e-mail client thinks it is using – IMAP +SMTP

Environmental Variables: 
Device: Tarako 1.3T MOZ 
BuildID: 20140429014002 
Gaia: b5adc5a943d3abbd6ab070a47c847f2c24891cc5 
Gecko: e9890f5d4709 
Version: 28.1
Firmware Version: sp6821a-gonk4.0-4-29
This issue does not reproduce on 1.3 Buri. Following STR from Comment 0 witnessed consistent and smooth transition between screens starting Email app, taking photo, adding attachment etc. 

Environmental Variables: 
Device: Buri 1.3 MOZ 
BuildID: 20140429024001 
Gaia: caab7a78f0c04913f48a3051259663ee85625906 
Gecko: f84a8ffbc552 
Version: 28.0
Firmware Version: v1.2-device.cfg
Wow... Good catch!

Can you check a couple of things for me please?
Under settings -> battery is power save mode turned on?
During this occurrence, can you check to see if it clears up after reboot please?

There's 2 things that I'm trying to understand.  If it has something to do with the power save mode and if it has something to do with having used the device for a really long time without rebooting.
Flags: needinfo?(mclemmons)
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #2)
> Wow... Good catch!
> 
> Can you check a couple of things for me please?
> Under settings -> battery is power save mode turned on?
> During this occurrence, can you check to see if it clears up after reboot
> please?
> 
> There's 2 things that I'm trying to understand.  If it has something to do
> with the power save mode and if it has something to do with having used the
> device for a really long time without rebooting.

1. During testing Apr. 30, 2014 with the situation described in Comment 0, power save mode was not turned on. 

2. During testing May 1, 2014 with the situation described in Comment 0, and power save mode enabled, user unable to reproduce behavior described in Comment 0. Device performance improved substantially with minimal to no screen lock experiences. Battery life remained at 19 percent from start to finish. 

3. During testing May 1, 2014 with the situation described in Comment 0 and power save mode disabled, user able to reproduce behavior described in Comment 0. Battery life dropped from 24 percent to 20 percent from start to finish. 

4. During testing May 1, 2014 with the situation described in Comment 0 and power save mode disabled and attempted to reboot the phone after poor device experience, device performance improved substantially after reboot – to the level of testing with power save mode enabled (#2 above). Battery life remained consistently at 19 percent from start to finish. 

Below are the environmental variables used for answers 1-4 above. 

Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140430014008
Gaia: f9b62bd1135f4edf8317fff1c2947b9d99438d79
Gecko: ba50f734b815
Version: 28.1
Firmware Version: sp6821a-gonk4.0-4-29
Flags: needinfo?(mclemmons)
Can this "poor device performance" experience happen in other places in the phone under the low battery conditions described in this bug?
Keywords: qawanted
Keywords: perf
(In reply to Jason Smith [:jsmith] from comment #4)
> Can this "poor device performance" experience happen in other places in the
> phone under the low battery conditions described in this bug?

Yes, this experience happens elsewhere on the phone. For example, today on Friday's build, I attempted to send an SMS with 2 picture attachments (476kb and 88kb) from Gallery with power mode turned off and battery percentage at 15. The SMS and attachments were sent but it struggled (took nearly 2 minutes to complete) and caused the battery to lose 11 percentage points during the process. 

Environmental Variables
Device: Tarako 1.3T MOZ
BuildID: 20140502014001
Gaia: a8e0ff550de08e58e4bf75af3cecf175b9b71e70
Gecko: 71790bf476cb
Version: 28.1
Firmware: sp6821a-gonk4.0-4-29
Keywords: qawanted
Component: Gaia::E-Mail → Performance
There seems to be quite a nasty problem here - the phone drops down to a crawl when the battery goes below 25% in multiple phone functions. We need to get this fixed.
blocking-b2g: --- → 1.3T?
ni? James on comment 6
Flags: needinfo?(james.zhang)
I think the phone is not calibrated.
Loop Sam, can you help mozilla to calibrate the phone?
Flags: needinfo?(james.zhang) → needinfo?(sam.hua)
we will ask our test team to reproduce it.
yiwen will take it.
Flags: needinfo?(sam.hua) → needinfo?(yiwen.liu)
triage: phone should not slow down when battery is low. 1.3T+ [POVB]
blocking-b2g: 1.3T? → 1.3T+
Whiteboard: [tarako-exploratory] → [tarako-exploratory][POVB]
I got a test.

Two scenes: battery with 95% and 3%

95%:
  1. Write Message,add attachment from Gallery or camera, add attachment again and again.
  2. New E-mail ,add attachment from Gallery or camera, add attachment again and again.
and battery with 3% did the same actions.

"slowly" and "black screen" happened at all of the two scenes.
And at the memont , from the log, the "Message" or "E-mail" was killed by LMK:

"""
<4>0[ 1962.901212] lowmem_shrink select 2604 (E-Mail), adj 2, size 13803, to kill
<4>0[ 1962.901232] lowmem_shrink send sigkill to 2604 (E-Mail), adj 2, size 13803
<4>0[ 1962.901247] E-Mail invoked lowmemorykiller: gfp_mask=0x200da, oom_adj=2, oom_score_adj=134
"""

The object that was killed is E-Mail,and the trigger is also E-Mail , and now "a black screen" there!
Flags: needinfo?(yiwen.liu)
Assignee: nobody → yiwen.liu
Priority: -- → P1
Whiteboard: [tarako-exploratory][POVB] → [tarako-exploratory][POVB][c= p= s= u=]
Whiteboard: [tarako-exploratory][POVB][c= p= s= u=] → [tarako-exploratory][POVB][c=progress p= s= u=tarako]
Status: NEW → ASSIGNED
Any suggestions?
(In reply to yiwen.liu from comment #13)
> Any suggestions?

Please comment your test result here.
(In reply to yiwen.liu from comment #12)
> I got a test.
> 
> Two scenes: battery with 95% and 3%
> 
> 95%:
>   1. Write Message,add attachment from Gallery or camera, add attachment
> again and again.
>   2. New E-mail ,add attachment from Gallery or camera, add attachment again
> and again.
> and battery with 3% did the same actions.
> 
> "slowly" and "black screen" happened at all of the two scenes.
> And at the memont , from the log, the "Message" or "E-mail" was killed by
> LMK:
> 
> """
> <4>0[ 1962.901212] lowmem_shrink select 2604 (E-Mail), adj 2, size 13803, to
> kill
> <4>0[ 1962.901232] lowmem_shrink send sigkill to 2604 (E-Mail), adj 2, size
> 13803
> <4>0[ 1962.901247] E-Mail invoked lowmemorykiller: gfp_mask=0x200da,
> oom_adj=2, oom_score_adj=134
> """
> 
> The object that was killed is E-Mail,and the trigger is also E-Mail , and
> now "a black screen" there!

Write new message, b2g-info show:
Messages 1224  343    1.6    1  9.0 12.9 21.5  63.7(VSIZE)       2 app_1224

and then add attachment again and again , Messages's VSIZE can up to 114M, the oom_adj of message bigger than b2g/Nuwa/Preallocated a , and then LMK occurred!

Is it possable to reduce the memory of add attachment? Or should we limit the amount of attachment?
from this issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=1006882

I pull the lastest commit, the speed of add attachment is faster, but when attachment up to ten and more, notice that Message process's VSIZE had up to 104M, phone become slowly.
So I suggest that limit  the amount of attachment. 

mclemmons:
Could you take a new test with this issue "1006882" fixed?
Flags: needinfo?(mclemmons)
Keywords: qawanted
(In reply to yiwen.liu from comment #16)
> from this issue:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1006882
> 
> I pull the lastest commit, the speed of add attachment is faster, but when
> attachment up to ten and more, notice that Message process's VSIZE had up to
> 104M, phone become slowly.
> So I suggest that limit  the amount of attachment. 
> 
> mclemmons:
> Could you take a new test with this issue "1006882" fixed?

Following STR in Comment 0 with low battery (<25 percent), Apps open consistently without slow reactions and without vanishing visuals on the latest 1.3T build. This was tested successfully on 7 occasions. 

Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140508014002
Gaia: 8969848adfdd8b0cfdfdf072f99b20505385482c
Gecko: 1d997ccbf79c
Version: 28.1
Firmware Version: sp6821a-gonk4.0-4-29
Flags: needinfo?(mclemmons)
Keywords: qawanted
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → 2.0 S1 (9may)
You need to log in before you can comment on or make changes to this bug.