Ilya, Pat.. is there any current data available on the latency distributions for 3G and 4G?

Turning on restrict-google in case we discuss the numbers from  https://goto.google.com/inferring-latency

philip, I'd like to get some more real-world numbers for latency and throughput for various mobile connectivity categories.

Basically the presets we have in DevTools are not accurate, as far as I can tell.

Do you have any data we can use to make some better estimates?

The WebPageTest profiles largely came from a combination of reports, experimenting and also validating against what Facebook published for their ATC traffic-shaping project: https://github.com/facebook/augmented-traffic-control/tree/master/utils/profiles

Great. I just asked about where their numbers are sourced from: https://github.com/facebook/augmented-traffic-control/pull/89​

FWIW, we do have latency UMA metrics: https://uma.googleplex.com/p/chrome/histograms/?endDate=03-20-2016&dayCount=1&histograms=Net.TCP_Connection_Latency&fixupData=true&showMax=true&analysis=0.1%200.2%200.3%200.4%200.5%200.6%200.7%200.75%200.8%200.9%200.95%200.98%200.99%200.995&filters=channel%2Ceq%2C1%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

UMA doesn't allow breakdown by interface type, but we can pull that data via Dremel. I believe toyoshim@ did just that, relatively recently, for font fetch latency.

I'm recently interested in such numbers for launching WebFonts intervention, but actually I didn't add them by myself. Luckily I'm just a user here.

The UMA page suggests mmenke is the owner of this metric.

Also NQE.* must contain several data you are also interested in. There you can see network quality data per network connection type in the real world, e.g. RTT for 2G or something.
I add NQE owners to CC.

FWIW: Android Emulator has a few presets for latency and throughput: http://developer.android.com/tools/devices/emulator.html#netdelay Though I think they're a bit dated, and in general I think exposing network-type presets is less valuable to users that just presenting the "representative" numbers that you want them to use.

bengr@, can i use NQE.RTTObsevations numbers as indicative of real world RTT and latency for 2g,3g, etc? 

NQE.RTTObsevations is RTT at the HTTP layer. I believe DevTools requires RTT at the transport layer.

I have a pending CL that will push RTT information from TCP sockets to NQE where I am going to record it in UMA. In the meantime, it seems that "Net.TcpRtt.AtDisconnect"  would be more suitable for DevTools.

Adding bmcquade who added "Net.TcpRtt.AtDisconnect".

I'm confused.  Why are we CCing people who own various histograms?

I'll back up, as the ticket assumed some inside knowledge. :)  

We have an enormous population of web developers that use network throttling via Chrome DevTools to mimic mobile network conditions and use this to profile pageload and iteratively improve their perf. 

We offer a few presets for latency & throughput in the tool (Regular 3G, Good 3G, etc). However, I can't justify the numbers we use for those metrics and, to be honest, they are not representative.  (For example, "Good 3G" does not have a 40ms RTT in reality.)

We'd like to have more accurate throttling that's representative of real mobile connections. I'm asking folks on this thread for pointers on our current trusted numbers are for throughput & latency. In particular, if we have throughput/RTT histograms in UMA that is representative of all cellular mobile users or broken by 2g,3g,etc, I'd love to know which histograms in particular are recommended. I'll then poke at the percentiles to determine a "typical" value. 


(There's a separate discussion about the quality and impl of throttling, but this issue is only about defining good presets)

We do record the connection type when stats are recorded, but you'll need to run database queries manually to divide up the data that way, since it's not available in the dashboard.  I've never had the time to figure out the details of doing that, though.

@mmenke, which uma histograms should i look at for throughput and latency?

Sorry for being so explicit, but theres hundreds and the answer is often "oh that's bad data", so I wanted to make sure I'm using the best ones.

I'm not sure we record either.  We tend to trying to measure network stack performance, rather than network conditions.

Bulk DevTools triage, closing low priority issues with no action plan.