New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 713636 link

Starred by 1 user
Status: WontFix
Owner:
tbansal@chromium.org
Closed: Apr 2017
Cc:
█ amineer@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

GetSignalStrengthDbm blocks the IO thread on Android

Project Member Reported by horo@chromium.org, Apr 20 2017 
Chrome Version: M57
OS: Android

What steps will reproduce the problem?
1. Checkout M57 (branch 2987) to build Android Chrome.
2. Apply the patch https://crrev.com/2833753002/ to add TRACE_EVENTs
3. Build chrome_public_apk and install the apk to the android device.
4. On the device:
 4.1. Open https://horo-test.appspot.com/navigationpreload/demo/
 4.2. Click "Register SW" button
 4.3. Click "test" link
5. On the PC:
 5.1. Open chrome://inspect/?tracing#devices
 5.2. Click "close" of Worker.
 5.3. Click "trace" to chrome://tracing/ of the device
 5.4. Click "Record" -> Manually select settings
 5.5. Select all "Record Categories"
 5.6. Select "loading", "net" and "network" of "Disabled by Default Categories".
 5.7. Click "Record"
 5.8. Click "reload" of chrome://inspect/?tracing
 5.9. Click "Stop" of chrome://tracing/

The attached image is the trace of Nexus 4 (Android 5.1.1).

cellular_signal_strength::GetSignalStrengthDbm is blocking the IO thread 70 ms.
This demo site is using ServiceWorker Navigation Preload.

If the server returns the preload response quickly, and GetSignalStrengthDbm() is
executed while Chrome is starting the ServiceWorker. This causes the service
worker startup latency.

I think this patch (https://crrev.com/976a4b6) was merged to M58, so this problem
doesn't happen on M58 if NQE experiment is disabled.
But if NQE is enabled, this problem will happen again.

To: NQE team
Is the cost of GetSignalStrengthDbm on the IO thread "70ms" appropriate?
slow_get_signal.png
122 KB View Download

Comment 1 by tbansal@chromium.org, Apr 20 2017

Status: WontFix (was: Untriaged)
Thanks for filing this.

As you noticed, the NQE experiment has been disabled for M-58 and onwards, so the blocking won't happen on M-58+. Back then, it was decided not to merge back the fix to M-57 since it was past the stable release candidate.

The long term fix is to remove the existing code, use PhoneStateListener to listen to changes in the signal strength, and then re-enable the NQE experiment.

I am closing this as WontFix since there is nothing to be done for M-57, and the offending code does not run on M-58+. Feel free to reopen if there are any suggestions.

Comment 2 by horo@chromium.org, Apr 20 2017 

I have one question.
I think 70 ms is a big performance problem. 
This probrem occurs even if the site is not using service worker.

Didn't the perf bots detect any regression?
Haven't you received any regression report yet?

Comment 3 by tbansal@chromium.org, Apr 20 2017 

No, there were no regression reports from perf bots. Initially (M-57 and before), the call to GetSignalStrengthDbm was unconditional. M-58 and later versions guarded the call behind the NQE experiment.

Do you see the regression when the device is connected to cellular network or Wi-Fi or does the regression happen regardless of the network type?

Comment 4 by horo@chromium.org, Apr 20 2017 

I tested with wifi.

I received a regression report mail about service worker navigation preload.
While I was inspecting the regression, I found that something is blocking the IO thread.
I think it is caused by NQE.
But I don't have 100% confidence.


I CCed the mail to you.

Comment 5 by tbansal@chromium.org, Apr 20 2017

Labels: M-57
Thanks. Right, the problem is only on M-57 and earlier versions.
►

Sign in to add a comment