Create a field trial to test if we can detect good QPC implementations.

chrome/browser/metrics/time_ticks_field_trial_win.cc

Index: chrome/browser/metrics/time_ticks_field_trial_win.cc
diff --git a/chrome/browser/metrics/time_ticks_field_trial_win.cc b/chrome/browser/metrics/time_ticks_field_trial_win.cc
new file mode 100644
index 0000000000000000000000000000000000000000..f71a55d3bbf41edead907b2dcbc00bf7aad49c1a
--- /dev/null
+++ b/chrome/browser/metrics/time_ticks_field_trial_win.cc
@@ -0,0 +1,77 @@
+// Copyright (c) 2013 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 "chrome/browser/metrics/time_ticks_field_trial_win.h"
+
+#if defined(OS_WIN)
+
+#include "base/cpu.h"
+#include "base/metrics/field_trial.h"
+#include "base/metrics/histogram.h"
+#include "base/win/windows_version.h"
+
+#include <windows.h>
+
+namespace chrome_browser_metrics {
+
+namespace {
+
+const int kNumIterations = 1000;
+
+}  // anonymous namespace
+
+void CollectTimeTicksStats() {
+  // This bit is supposed to indicate that rdtsc is safe across cores. If so, we
+  // can use QPC as long as it uses rdtsc.
+  // TODO(simonjam): We should look for other signals that QPC might be safe and

[Sigurður Ásgeirsson, 2013/04/04 12:35:14]

On Windows XP, QPC is going to be a system call even when the cycle counter
(rdtsc) is used for timing, so QPC will perform poorly compared to a raw rdtsc
instruction.
You could measure this by bracketing your QPC calls by rtdsc calls, and grabbing
the min value of the invocation cost as a metric.
I predict you'll see tens of cycles for QPC on Vista and up, versus a couple of
thousand cycles on XP.

+  // test them out here.
+  base::CPU cpu;
+  UMA_HISTOGRAM_BOOLEAN("WinTimeTicks.NonStopTsc",
+                        cpu.has_non_stop_time_stamp_counter());
+  if (!cpu.has_non_stop_time_stamp_counter()) {
+    return;
+  }
+
+  base::win::OSInfo* info = base::win::OSInfo::GetInstance();
+  UMA_HISTOGRAM_ENUMERATION("WinTimeTicks.VersionTotal", info->version(),
+                             base::win::VERSION_WIN_LAST);

[Sigurður Ásgeirsson, 2013/04/04 12:35:14]

nit: wonky indent.

+
+  LARGE_INTEGER qpc_frequency;
+  QueryPerformanceFrequency(&qpc_frequency);
+
+  int min_delta = 1e9;
+  LARGE_INTEGER qpc_last;
+  QueryPerformanceCounter(&qpc_last);
+  for (int i = 0; i < kNumIterations; ++i) {
+    LARGE_INTEGER qpc_now;
+    QueryPerformanceCounter(&qpc_now);

[darin (slow to review), 2013/04/04 06:15:11]

Perhaps it would make sense to insert some calls to Sleep(0) to provoke a
context switch?  that might help exacerbate any issues with QPC being out of
sync across CPU cores.

[Sigurður Ásgeirsson, 2013/04/04 12:35:14]

You can also deliberately cycle the thread across cores by playing with
SetThreadAffinityMask. AFAIK, on a successful return from SetThreadAffinityMask,
you'll be running under the new mask, e.g. on a new core if you roll a single
bit around in the mask.

[jar (doing other things), 2013/04/04 16:58:49]

I was thinking about suggesting a sleep...

but decided it was counter productive.  Sleeps will probably take some
significant time (>1ms) and would probably miss the bug, where the clock moves
backwards (and I'd assume backwards only slightly, like less than 1ms).

Is my analysis incorrect, and does bug surrounding the "clock going backwards as
you change cores" create large (>1ms) deltas that could be detected after a
sleep?

In the end, I conjectured that we'll hopefully detect problems (if any) by
running on sooooo many machines, that a suspend and core switch would hit us in
the middle of the loop.

Maybe it would be nice to ask what core we were on at the start of the loop, and
what core we were on at the end of the loop, and see if things changed?  That
might give us a measure of how often we had a *chance* to identify the bug. I'm
not real sure what the function might be, but perhaps something like
GetLogicalProcessorInformationEx() would give us such info.

On 2013/04/04 06:15:11, darin wrote:

+    int delta = static_cast<int>(qpc_now.QuadPart - qpc_last.QuadPart);

[Sigurður Ásgeirsson, 2013/04/04 17:17:18]

If the whole point of this is to identify when different cores are out of sync
with respect to QPC or rdtsc, then here's perhaps a better way to do it: probe
each core in turn, and to correlate the QPC/rdtsc clock back to the system
clock, or some other known-good time reference.
The resolution of the system clock is a hindrance to this (down to 15ms) but
perhaps this can be done by cycling over cores, busy waiting for a clock tick
and using the edge of the tick as a reference (assuming it's regular and
accurate).

Another sneaky way to do this would be to spawn as many threads as there are
cores, assign each to a different core, hike them all in priority and let them
all block on an event but one.
When the event is signalled, all the threads should unblock more-or-less
simultaneously. By signalling back to the unblocking thread you can bound the
time span this takes across all the threads. If any of the captured clocks is
outside the time span from start to end, then you've caught messed-up clocks.

+    if (delta != 0) {
+      min_delta = std::min(min_delta, delta);
+    }
+    qpc_last = qpc_now;
+  }
+
+  if (min_delta >= 0) {
+    UMA_HISTOGRAM_ENUMERATION("WinTimeTicks.NonDecreasing", info->version(),
+                              base::win::VERSION_WIN_LAST);
+  } else {
+    return;
+  }
+
+  int min_delta_us = static_cast<int>(
+      min_delta * (1e6 / qpc_frequency.QuadPart));
+  UMA_HISTOGRAM_CUSTOM_COUNTS("WinTimeTicks.MinResolutionMicroseconds",
+                              min_delta_us, 1, 1000, 50);
+
+  bool success = min_delta_us <= 100;  // Our goal is 0.1ms resolution.
+  if (success) {
+    UMA_HISTOGRAM_ENUMERATION("WinTimeTicks.VersionSuccessful",
+                              info->version(), base::win::VERSION_WIN_LAST);
+  }
+}
+
+}  // namespace chrome_browser_net
+
+#endif  // defined(OS_WIN)