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

Issue 753215 link

Starred by 1 user

Issue metadata

Status: Archived
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

Determine optimal BLE parameters

Project Member Reported by hansberry@chromium.org, Aug 8 2017

Issue description

We currently advertise at a min of 100ms and max of 100ms (these are realistically the smallest intervals we can request of Bluez).

Investigate if we can up the min or max interval without sacrifice of connection reliability -- doing so will improve battery life.
 
Summary: Determine optimal BLE parameters (was: Determine optimal BLE advertising interval min and max)
In addition to advertising intervals, we should also optimize our other Bluetooth parameters:

(1) When starting a connection, we wait 10 seconds for each connection attempt, but in my experience, it seems like connections either succeed rather quickly (within 2-3 seconds) or fail entirely. This means that in failure cases, we often wait way longer than we really need to before giving up, and while we are waiting, the UX shows an animated spinner for host scans and animated cellular signal icons for connection attempts. It would be nice if we could shorten this period so that when these events are unsuccessful, they fail quickly and provide more immediate user feedback.

(2) We should revisit our protocol timeouts to ensure that they are appropriate.
Kyle: Do you have histogram data about how long the connecting takes?  We should use that data to make this decision.
No, we currently don't have that data. hansberry@, let's add that metric as part of the fix for this issue.
Owner: khorimoto@chromium.org
Taking this issue from hansberry@.

FYI, the metrics listed in comment #3 are now part of issue 754445.
Status: Started (was: Assigned)
Talking to the Bluetooth team, it seems that our 100ms intervals look good.

I also checked to see how long it actually takes to connect to devices as I stated in comment #1. It seems that connections can reasonably take up to 6s in success cases, so it seems our 10s timeout is reasonable.

Looks like the only thing really to be done here is to remove Ryan's TODO.
Project Member

Comment 6 by bugdroid1@chromium.org, Aug 23 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/06e438b147822624bfc81f47677c4b65ddf3f660

commit 06e438b147822624bfc81f47677c4b65ddf3f660
Author: Kyle Horimoto <khorimoto@google.com>
Date: Wed Aug 23 21:45:43 2017

[CrOS Tether] Remove TODO to investigate BLE advertising interval.

I've tried with other intervals and have talked to the Bluetooth team
about this. 100ms seems like the right value.

Bug:  753215 , 672263
Change-Id: If59b99d945ca0f08e63bf1c9a7bae78fdbdd9726
Reviewed-on: https://chromium-review.googlesource.com/629636
Reviewed-by: Ryan Hansberry <hansberry@chromium.org>
Commit-Queue: Ryan Hansberry <hansberry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#496816}
[modify] https://crrev.com/06e438b147822624bfc81f47677c4b65ddf3f660/chrome/browser/chromeos/tether/tether_service.cc

Status: Fixed (was: Started)

Comment 8 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment