I think this makes some sense. However our network throttling settings treat RTT as a property of the network as a whole, rather than a property of a single server. Even though we aren't connecting directly to the origin's server, that RTT time is still a necessary step for connecting to the origin.

Perhaps the most accurate calculation would involve separating the DNS RTT from the actual server RTT but that probably isn't worth the effort.

I can't say I'm swaying in one direction or the other at this point, but the difference seems to be minimal.

I think this makes some sense. However our network throttling settings treat RTT as a property of the network as a whole, rather than a property of a single server.

(relevant code: load-simulator.js)

The Simulator's options.rtt is indeed a property of the local network - how much additional rtt to add to every request on 3g for example. But there is also options.additionalRttByOrigin. The network analyzer computes both a rtt (the minimum of the observed rtt to all origins) and additionalRttByOrigin (per-origin latencies) - the simulator's rtt is set to that observed minimum only for provided, but additionalRttByOrigin is always used.

I believe the Simulator's options.rtt property only wants to capture how much rtt to add to every outbound request, to any server (including DNS servers). The estimate given by NetworkAnalysis is exactly that, and for the reasons listed above it's best to exclude the highly variable DNS roundtrips from that estimate.

Updated branch, but let's wait for lantern trace database refresh.