[whatwg] XHR Level 2: Accurate Speed Measurement

Estimates aren't a bad thing; they're OK when exact data is impossible to ascertain. Reliability isn't a simple yes/no question; it's more of a scale. Right now, nothing we have is reliable whatsoever. I'd like to have something that's reliable within a relatively small most of the time, and I don't think that's too much to ask.
In my experience with large uploads/downloads, speed tends to start at 0, then rise quickly to the speed it tends to stay at throughout (higher, if you have Comcast or another ISP that boosts speeds at the beginning of downloads), then stay at around the same speed for the rest of the transfer, wavering if on a wireless connection or if another transfer starts on the same modem. Keeping all of this in mind, I think it would make sense to average several recent rates together (but not all since the start of the download), ignoring any flukes (e.g. 50% or more away from the median?), and weighting more recent results higher than older ones. The UA could choose how many recent rates to average based on the connection type and (possibly) a pre-tested average speed on a connection to a server which is known to be very fast.
I think a linear approximation for time remaining, assuming a correct content-length (return Infinity or undefined if no content-length?), is accurate enough for the purpose of estimates on a website.
completionTime (completionDate might be a better name) is just a concept for a convenience function, it's not really important by any stretch of the imagination. I just figured it might be useful to have, but I know one line of JS can do it as well.
The transferRate could be one of 3 things:
1. An average of all rates since the start (BAD IDEA)
2. The weighted average I described
3. The most recently calculated rate

I think 2 and 3 both have their merits and uses, so perhaps two properties would make more sense:
averageTransferRate = weighted average
currentTransferRate = most recent

I hope we can see progress on this!
--Rodger
On Nov 23, 2011, at 8:06 PM, Karl Dubost wrote:

> 
> Le 23 nov. 2011 ? 10:14, Rodger Combs a ?crit :
>> XHR currently provides no reliable method of determining the actual upload or download speed of a transfer. 
> 
> 
> There's a lot of issues to be able to do something like this.
> 
> 1. "reliable". The network is not reliable is the first issue. 
>   All data you would get would be an estimate.
> 2. The network speed is usually not linear.
> 
> # XHR.timeRemaining = estimated time left in ms
> 
> Let's assume, we got the right content-length header.
> The time remaining is a function of the download pattern which has already happened. An Integral to recalculate. Maybe a linear approximation is enough, not sure.
> 
> # XHR.completionTime = a Date object representing the estimated completion time
> 
> date.now() + XHR.timeRemaining is not ok?
> 
> 
> # XHR.transferRate = upload/download speed, measured in Kbps, as an integer.
> 
> So you are saying the current transferRate or the integral of the past transferRate from the beginning?
> 
> 
> -- 
> Karl Dubost - http://dev.opera.com/
> Developer Relations & Tools, Opera Software
>

Received on Wednesday, 23 November 2011 18:35:29 UTC