QUIC - add UMA histogram to track retransmit rate for large uploads.

net/quic/chromium/quic_chromium_client_session.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "net/quic/chromium/quic_chromium_client_session.h"
 
 #include <openssl/ssl.h>
 
 #include <utility>
 
@@ skipping 353 matching lines @@
   // (initial values and MTU discovery values), but does not fare well when
   // bucketed.  Because of that, a sparse histogram is used here.
   UMA_HISTOGRAM_SPARSE_SLOWLY("Net.QuicSession.ClientSideMtu",
                               connection()->max_packet_length());
   UMA_HISTOGRAM_SPARSE_SLOWLY("Net.QuicSession.ServerSideMtu",
                               stats.max_received_packet_size);
 
   UMA_HISTOGRAM_COUNTS("Net.QuicSession.MtuProbesSent",
                        connection()->mtu_probe_count());
 
+  if (stats.packets_sent >= 100) {
+    // Used to monitor for regressions that effect large uploads.
+    UMA_HISTOGRAM_COUNTS_1000(

[Ryan Hamilton, 2016/09/14 19:51:20]

I wonder if _100 might be better to avoid quantization artifacts? *shrug*

[Buck, 2016/09/14 19:56:14]

Wouldn't that make it worse?   That's why I chose UMA_HISTOGRAM_COUNTS_1000
instead of UMA_HISTOGRAM_PERCENTAGE (synonymous with _100 I believe).   If the
expected range of values is say 1-2%, true percentage is too coarse grained, as
opposed to 10-20 permille.

[Ryan Hamilton, 2016/09/14 20:41:16]

I was thinking of something different. If, for example, most streams have 100
packets then there are only 100 distinct values for the packet loss rate. If we
have 1000 buckets, we'll see data like X, 0, 0, 0, 0, 0, 0, 0, 0, 0, Y, 0, 0, 0,
0, 0, 0, 0, 0, 0, Z. That will end up looking like we have big spikes at
0,10,20, but in reality is just quantization artifacts.

You raise a good point that we might care about having higher resolution packet
loss rates than 1%. In order to have high fidelity here, I think we need
sessions with more than 100 distinct value. My guess is that the number of
packets sent per connection follows some sort of exponential slow down but I
could be totally wrong.

+        "Net.QuicSession.PacketRetransmitsPerMille",
+        1000 * stats.packets_retransmitted / stats.packets_sent);
+  }
+
   if (stats.max_sequence_reordering == 0)
     return;
   const base::HistogramBase::Sample kMaxReordering = 100;
   base::HistogramBase::Sample reordering = kMaxReordering;
   if (stats.min_rtt_us > 0) {
     reordering = static_cast<base::HistogramBase::Sample>(
         100 * stats.max_time_reordering_us / stats.min_rtt_us);
   }
   UMA_HISTOGRAM_CUSTOM_COUNTS("Net.QuicSession.MaxReorderingTime", reordering,
                               1, kMaxReordering, 50);
@@ skipping 1009 matching lines @@
 }
 
 const LoadTimingInfo::ConnectTiming&
 QuicChromiumClientSession::GetConnectTiming() {
   connect_timing_.ssl_start = connect_timing_.connect_start;
   connect_timing_.ssl_end = connect_timing_.connect_end;
   return connect_timing_;
 }
 
 }  // namespace net