Issue metadata
Sign in to add a comment
|
Flywheel disabled due to ERR_CONNECTION_TIMED_OUT on slow network |
||||||||||||||||||||||||
Issue descriptionApplication Version (from "Chrome Settings > About Chrome"): 56.0.2924.18 Android Build Number (from "Android Settings > About Phone/Tablet"): LXI22.50-62 Device: Moto E Steps to reproduce: 1) Put device on a slow network (e.g., GIN-2gpoor) 2) Enable Flywheel. 3) Try to load a page. Observed behavior: In this case, I loaded a page successfully with Flywheel (with Lo-Fi and Lite Pages on). When I tapped on "Show original", the page load took a VERY long time and eventually resulted in an ERR_CONNECTION_TIMED_OUT error page. When I loaded the page again, Flywheel had been disabled. Looking in chrome://net-internals#bandwidth, I see: 2016-12-08 11:18.49.765 net_error ERR_CONNECTION_TIMED_OUT proxy https://proxy.googlezip.net:443 2016-12-08 11:18.49.765 net_error ERR_CONNECTION_TIMED_OUT proxy compress.googlezip.net:80 Netlog from the entire session attached. Expected behavior: This is a typical problem for users in poor connectivity situations. When the device is on a slow network, we should reconsider our policy for timing out and retrying network connections (maybe in general, but at least for Flywheel). Disabling Flywheel in this case was probably harmful for the user, since the user would not get the benefit of compression and speedup. Clearly we also need to time out in cases where Flywheel really cannot be reached, but the expectation that Google is down would probably be less than the network were simply slow. In this case, we might want to retry the connection to Flywheel first and only give up if we are confident that nothing is getting through. See internal doc for more details on experiment: https://docs.google.com/a/google.com/document/d/19ctmz25Dd4FsCUeFJeaIhWGBTENcVo5_KD626fRE4DM/edit?usp=sharing
,
Dec 9 2016
Thank you for your response what is flywheel
,
Dec 9 2016
Flywheel is the alternative name of Chrome data saver (https://support.google.com/chrome/answer/2392284?co=GENIE.Platform%3DAndroid&hl=en).
,
Dec 21 2016
Tarun, since this is related to work you're planning, I'm assigning to you. To summarize the comments in this issue, I think there are several avenues to explore: 1) Tune proxy (and probably socket) timeouts using NQE. 2) Retry Google connections (or, to generalize, any highly reliable hosts), before giving up. 3) Use a combination of redundant connections and probes to restore a proxy after falling off of it.
,
Feb 25 2017
,
Feb 28 2017
,
Mar 16 2017
Whatever you do, make sure we are still responsive when a connection attempt is black holed by a captive portal.
,
Mar 22 2017
,
Mar 29 2017
,
May 24 2017
,
Jun 12 2017
,
Aug 22 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by tbansal@chromium.org
, Dec 9 2016