Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 172754 net-internals: bad timestamps after suspend/resume
Starred by 1 user Project Member Reported by quiche@chromium.org, Jan 29 2013 Back to list
Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment
Chrome Version       : 24.0.1312.56
OS Version: OS X 10.8.2

What steps will reproduce the problem?
1. open chrome://net-internals
2. suspend system (close lid)
3. clear net internals events
4. open a web page
5. examine net internals events

What is the expected result?
new events should have current time

What happens instead of that?
times are wrong. they're shifted backwards by the amount of time spent asleep.
e.g., if i resume at 4:00pm, after the system was asleep for 2 hours, the net-internals
timestamps will be 2:00pm.

workaround: close net-internals and re-open it.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17
 
Comment 1 by mmenke@chromium.org, Jan 29 2013
I don't think this is worth the effort of fixing.
Comment 2 by quiche@google.com, Jan 29 2013
FWIW, the reason I ran into this is that I was trying to correlate net-internals events with a pcap.
Comment 3 by eroman@chromium.org, Jan 29 2013
Status: Untriaged
The issue is that the NetLog uses timetics (base::TimeTicks()) rather than timestamps (base::Time()) when capturing events.

The behavior of timeticks across sleeps is platform specific (may or may not increase). Which makes converting them to timestamps unreliable if there were intervening sleeps.

I initially chose to use timeticks rather than timestamps to avoid the possibility of time moving backwards in events (if a user changes their system clock, later events may actually have an earlier timestamp).

The performance tradeoff between the two is negligeable.

Given this usecase, I think switching to using timestamps in place of timeticks might be a better tradeoff. (Likely more common to encounter suspend/resume than dramatic system clock changes; although with network time synching shifts in timestamps would also be expected).

The other possibility is to log suspend/resume events in the NetLog (something which we probably want to do anyway), and make note of the new timetick --> timestamp adjustment each time, so we can rebuild correct timestamps
Comment 4 by eroman@chromium.org, Jan 29 2013
@mmenke: I think we should switch from base::TimeTicks::Now() to base::Time::Now(), WDYT? It would be a simple solution to this problem, and I don't think cause problems.
Comment 5 by mmenke@chromium.org, Jan 29 2013
The two potential concerns are how monotonic it is and what its resolution is.

I assume the main causes of lack of monotonicity would be users modifying it and NTP (Network Time Protocol, not to be confused with the New Tab Page).

Resolution differences are presumably platform dependent.
Comment 6 by quiche@chromium.org, Jan 29 2013
Labels: OS-Chrome
Verified that this affects ChromeOS. (That's as expected, since Linux CLOCK_MONOTONIC doesn't include time suspended.)

Comment 7 by rsesek@chromium.org, Jan 31 2013
Labels: -OS-Mac -OS-Chrome OS-All
This is just an issue with an impl of base::TimeTicks. Also not the only place that we have/had problem.
Comment 8 by eroman@chromium.org, Jan 31 2013
Status: Available
Some extra data:
  * base::TimeTicks advances during sleep for Windows, however not Mac/Linux/Chromeos
  * the performance of base::TimeTicks::Now() and base::Time::Now() are pretty much identical.

On my Linux setup I got these runtimes:
    Time::Now -- 39.95 nanoseconds
    TimeTicks::Now -- 38.06 nanoseconds

According to a post on chromium-dev, scottmg reports Windows runtimes of 50 nanoseconds for each.

Ideally we would have a time class that could be used on all platforms to accomplish this.

Not sure what is worse -- using Time::Now() and potentially having the times in NetLogs jitter due to NTP, or using TimeTicks::Now() and having weirdness on Mac/Linux whenever the system is suspended.

Barring a suspend-independent tick class, I believe that Time::Now() is the lesser of the two evils.
Comment 9 by mmenke@chromium.org, Jan 31 2013
What about resolution?  Know that on at least some windows platforms, timegettime used to have pretty bad resolution.  And accuracy was dependent on whether the "high resolution media timer" was active or not.
FWIW, on the Linux kernel, I think CLOCK_BOOTTIME provides monotonic time that includes time in suspend. 
Perhaps then I will suggest adding something like:
  base::BootTicks

This will have the behavior of monotonically increasing, and reflect time spent in suspends. Or we should just define TimeTicks to act that way.
Project Member Comment 12 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Internals-Network-Logging Cr-Internals Cr-Internals-Network-Logging
Labels: -Pri-2 Pri-3
No activity, but this does still seem like something worth fixing.

Updating priority accordingly.
Project Member Comment 14 by sheriffbot@chromium.org, Dec 2
Labels: Hotlist-Recharge-Cold
Status: Untriaged
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Sign in to add a comment