Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(3196)

Unified Diff: base/time_unittest.cc

Issue 10257020: Add interface to system trace clock. (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src
Patch Set: Created 8 years, 8 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« base/time.h ('K') | « base/time_posix.cc ('k') | base/time_win.cc » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: base/time_unittest.cc
diff --git a/base/time_unittest.cc b/base/time_unittest.cc
index 9823147a33dac223d224726b3c988676cf8e7be6..302b8f1d3d2764953be858788d3a3fa010d449c5 100644
--- a/base/time_unittest.cc
+++ b/base/time_unittest.cc
@@ -503,6 +503,45 @@ TEST(TimeTicks, HighResNow) {
EXPECT_TRUE(success);
}
+TEST(TimeTicks, NowFromSystemTraceTime) {
+#if defined(OS_WIN)
+ // HighResNow doesn't work on some systems. Since the product still works
+ // even if it doesn't work, it makes this entire test questionable.
+ if (!TimeTicks::IsHighResClockWorking())
+ return;
+#endif
+
+ // Why do we loop here?
+ // We're trying to measure that intervals increment in a VERY small amount
+ // of time -- less than 15ms. Unfortunately, if we happen to have a
+ // context switch in the middle of our test, the context switch could easily
+ // exceed our limit. So, we iterate on this several times. As long as we're
+ // able to detect the fine-granularity timers at least once, then the test
+ // has succeeded.
+
+ const int kTargetGranularityUs = 15000; // 15ms
jar (doing other things) 2012/04/27 22:50:18 Ordinary system clocks can be set to run faster th
Sam Leffler 2012/04/27 22:56:07 This is c&p of the HighRes test; I did not write t
jar (doing other things) 2012/04/30 22:05:57 I see now. I read this as new code, and made comm
Sam Leffler 2012/04/30 22:47:58 Done.
+
+ bool success = false;
+ int retries = 100; // Arbitrary.
jar (doing other things) 2012/04/27 22:50:18 100 sounds plausible.... but it is always nice to
Sam Leffler 2012/04/27 22:56:07 I don't see the HighRes test failing so think this
+ TimeDelta delta;
+ while (!success && retries--) {
+ TimeTicks ticks_start = TimeTicks::NowFromSystemTraceTime();
+ // Loop until we can detect that the clock has changed. Non-HighRes timers
+ // will increment in chunks, e.g. 15ms. By spinning until we see a clock
+ // change, we detect the minimum time between measurements.
+ do {
+ delta = TimeTicks::NowFromSystemTraceTime() - ticks_start;
+ } while (delta.InMilliseconds() == 0);
jar (doing other things) 2012/04/27 22:50:18 Why don't you look for any change? Why does the m
Sam Leffler 2012/04/27 22:56:07 Again, this is just the existing HighRes test; if
+
+ if (delta.InMicroseconds() <= kTargetGranularityUs)
+ success = true;
+ }
+
+ // In high resolution mode, we expect to see the clock increment
+ // in intervals less than 15ms.
+ EXPECT_TRUE(success);
+}
+
TEST(TimeDelta, FromAndIn) {
EXPECT_TRUE(TimeDelta::FromDays(2) == TimeDelta::FromHours(48));
EXPECT_TRUE(TimeDelta::FromHours(3) == TimeDelta::FromMinutes(180));
« base/time.h ('K') | « base/time_posix.cc ('k') | base/time_win.cc » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698