New issue
Advanced search Search tips

Issue 172754 link

Starred by 0 users

Issue metadata

Status: Untriaged
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Sign in to add a comment

net-internals: bad timestamps after suspend/resume

Project Member Reported by, Jan 29 2013

Issue description

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, Jan 29 2013

I don't think this is worth the effort of fixing.

Comment 2 by, 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, 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, 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, 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, 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, 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, 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, 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:

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, 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, Dec 2 2016

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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 - Your friendly Sheriffbot
Components: -Internals

Sign in to add a comment