Log UMA for navigation start timestamp skew for browser-initiated loads

tools/metrics/histograms/histograms.xml

Index: tools/metrics/histograms/histograms.xml
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml
index a5b6f8f4edeb4ce5b64324100aab94298fabb355..b9d5253abcfb5e4180df10a95142b89347ffe029 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -20778,6 +20778,32 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries.
   </summary>
 </histogram>
 
+<histogram name="Navigation.Start.RendererBrowserDifference.Negative"
+    units="milliseconds">
+  <owner>csharrison@chromium.org</owner>
+  <summary>
+    The difference between Now() in the renderer and browser_navigation_start
+    for browser-initiated navigations if the difference is negative. This value
+    should ideally only reflect the IPC time between the browser process and

[clamy, 2015/11/06 10:58:51]

On transfer navigations, this difference covers more than just the IPC time
(same with PlzNavigate btw). Should we exclude these cases from the metric?

[Charlie Harrison, 2015/11/06 13:35:19]

Huh, I could have sworn that this comment included something about transfers /
suspensions. Tbh I'm not totally sure what the right move is. Is there an easy
way to test renderer-side that this was a transfer? 
transferred_request_request_id != -1? I'd also be willing to increase the timing
window and just observe two humps on the histogram by logging everything. Could
be a somewhat useful metric in its own right. WDYT?

[clamy, 2015/11/06 14:07:02]

transferred_request_request_id != -1 identifies a transferred request. The risk
with increasing the window is that you will have less fine grained results for
smaller values, which I think we care more about. My recommendation would be to
live the window as is, with the possibility of excluding transfer navigations if
there are too many of them (I don't think it's the case).

Suspended navigations are not an issue: a navigation is only suspended when it
is cross site and we are waiting for the current renderer to execute its
BeforeUnload event. Since we update the navigation start at the moment when the
user clicks on proceed, we should not see a big discrepancy between the browser
navigation start and the renderer navigation start.

[Charlie Harrison, 2015/11/06 14:42:35]

Ah okay thanks for the clarification, I was conflating the two. Transfers happen
for cross site redirects? I'm fine with keeping the window and changing it up if
we want to see a longer tail / remove the longer tail. We can always change the
positive window and keep the negative window tiny.

+    renderer process, but in practice could be skewed by inter-process timing
+    errors. If the clocks used for TimeTicks are monotonic across processes, all
+    samples should fall into the Positive bucket.
+  </summary>
+</histogram>
+
+<histogram name="Navigation.Start.RendererBrowserDifference.Positive"
+    units="milliseconds">
+  <owner>csharrison@chromium.org</owner>
+  <summary>
+    The difference between Now() in the renderer and browser_navigation_start
+    for browser-initiated navigations if the difference is positive. This value
+    should ideally only reflect the IPC time between the browser process and
+    renderer process, but in practice could be skewed by inter-process timing
+    errors. If the clocks used for TimeTicks are monotonic across processes, all
+    samples should fall into the Positive bucket.
+  </summary>
+</histogram>
+
 <histogram name="Navigation.TimeToCommit" units="milliseconds">
   <owner>carlosk@chromium.org</owner>
   <summary>