RE: detecting connection speed

"auto detection will always be unreliable" 

and 

"I also believe there are better ways of solving the related issues" 

pretty much sum up my take on the issue.




-----Original Message-----
From: Jonny Rein Eriksen [mailto:jonnyr@opera.com] 
Sent: Thursday, December 05, 2013 4:55 AM
To: public-web-perf@w3.org
Subject: Re: detecting connection speed

On 05.12.2013 11:43, Charles McCathie Nevile wrote:
> On Thu, 05 Dec 2013 11:11:16 +0100, James Graham 
> <james@hoppipolla.co.uk> wrote:
>
>> On 04/12/13 19:44, Aaron Heady (BING AVAILABILITY) wrote:
>>
>>> In my experience, determining it on a per request basis just has too 
>>> much variance. Maybe if the UA kept its own set of statistics on a 
>>> per origin IP + current default gateway basis and knew that it was 
>>> generally good or bad for a given connection pair then it could pass 
>>> that hint along, maybe include a confidence hint with it (fast last
>>> 99 of 100 connections). If that mobile device thinks it is always 
>>> fast to an IP given its current proxy, then it most likely is.
>>
>> So, I don't know exactly how it worked but Opera trie[s|d] to do 
>> something like this to hint at when the "turbo" compression feature 
>> should be enabled. In my experience it wasn't exactly reliable; I 
>> don't think I was alone in getting the "slow connection" popup when I 
>> knew perfectly well that I wasn't on a slow connection at all.

What I did for measuring connection speed and display the "Use Turbo" 
hint was to measure at least 10 page loads over at least 10 minutes. If the cumulative bitrate for all browser connections per second across any of those page loads was above 256K we would not display the hint. I did take into account local/private/internet connections and would not count local/private page loads. This was for Presto. For Opera 15+ I just thought that users are better off deciding for themselves if they want Turbo/Offroad or not since auto detection will always be unreliable.

The problem is of course that any parallel network activity will cause slow page loads and give false positives. Along with all reasons listed previously in this thread. In general it is a difficult problem and connection speed can and will vary from minute to minute depending on network conditions, network load etc.

I would like to be able to tell a website how fast the user agent connection is, but I also believe there are better ways of solving the related issues.

>
> We do something similar with Turbo, using our own code for deciding 
> when to apply it. This is a use case for a browser.

Yandex did something similar with Turbo as we did with Presto, but I 
guess you do not display a notice, just turn Turbo on and off, so it is 
not as annoying.

>
> A more generalised version may be a site (e.g. single-page app, 
> although it also applies to multi-page) that stays open a "long time" 
> and downloads a number of resources during that time. Somewhat like 
> the responsive images use cases, there may be multiple resources that 
> can be offered, and the expected speed of a connection is a 
> determining factor for the server to choose the most appropriate 
> version of given resources.
>
> The obvious question is whether anyone can share a real and concrete 
> version of that use case - making up theoretical problems is easy, but…
>
> cheers
>
> Chaals
>

Received on Thursday, 5 December 2013 16:44:59 UTC