NetLog: Use TimeTicks::UnixEpoch() to calculate timeTickOffset.

NetLog:  Use TimeTicks::UnixEpoch() to calculate timeTickOffset.

This addresses a TODO and removes an ugly constant from NetLog.  On
the down side, TimeTicks::UnixEpoch() is cached, which may result in
less accuracy (And all bets are off if Chrome is suspended to disk).

BUG=488660
Committed: https://crrev.com/4971527414277e94682e664bf94df2274c94d17e
Cr-Commit-Position: refs/heads/master@{#330376}

[mmenke, 2015-05-15 23:29:04]

mmenke@chromium.org changed reviewers:
+ eroman@chromium.org

[eroman, 2015-05-15 23:37:32]

LGTM. But the suspend case sounds like a worse behavior, can you elaborate on
that?

[mmenke, 2015-05-15 23:49:22]

On 2015/05/15 23:37:32, eroman (sick slow) wrote:
> LGTM. But the suspend case sounds like a worse behavior, can you elaborate on
> that?

If you suspend to disk, your CPU shuts down, and then restores process state
from memory.  The cached value of TimeTicks::UnixEpock() will be restored.  I
assume that rdtsc will start with 0 again once you resume, so time ticks before
and after you suspend to disk won't be comparable, unless the OS have some
workaround for this.  I don't believe other suspend/sleep modes do this, though
I could certainly be wrong.

Another option would be to use:

int64 blah = (base::Time::Now() - base::Time::UnixEpoch()).InMilliseconds();
int64 delta = (base::TimeTicks::Now() - base::TimeTicks()).InMilliseconds() -
blah;

(Or something like that).  That doesn't have the problem.  Since the potential
problem is the caching behavior of base::TimeTicks::UnixEpoch(), I think I'd
rather just assume the method in base method works, rather than worrying about
it potentially being broken in usual cases...And note that if we get the wrong
time, net-internals is still completely functional.  The only problem would be
the absolute times it reports may be off.

I should say I have no recent experience with suspend to disk - seems like it
isn't enabled by default on any of my devices (Or at least is only used if you
run out of power), so it could be everything just works.

[mmenke, 2015-05-15 23:59:55]

Ahh....Looks like Windows, at least, handles it:

QueryPerformanceCounter reads the performance counter and returns the total
number of ticks that have occurred since the Windows operating system was
started, including the time when the machine was in a sleep state such as
standby, hibernate, or connected standby.

Unless you object, I'll just land it (After branch), and we'll see if we ever
get nonsense numbers.  May be worrying about nothing.

[mmenke, 2015-05-16 00:02:04]

On 2015/05/15 23:59:55, mmenke wrote:
> Ahh....Looks like Windows, at least, handles it:
> 
> QueryPerformanceCounter reads the performance counter and returns the total
> number of ticks that have occurred since the Windows operating system was
> started, including the time when the machine was in a sleep state such as
> standby, hibernate, or connected standby.
> 
> Unless you object, I'll just land it (After branch), and we'll see if we ever
> get nonsense numbers.  May be worrying about nothing.

And a clearer discussion: 
http://blogs.msdn.com/b/oldnewthing/archive/2008/09/08/8931563.aspx

[eroman, 2015-05-17 22:46:31]

lgtm

[mmenke, 2015-05-18 14:50:02]

The CQ bit was checked by mmenke@chromium.org

[commit-bot: I haz the power, 2015-05-18 14:50:46]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1127133008/1

[commit-bot: I haz the power, 2015-05-18 16:47:38]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-05-18 22:40:26]

Patchset 1 (id:??) landed as
https://crrev.com/4971527414277e94682e664bf94df2274c94d17e
Cr-Commit-Position: refs/heads/master@{#330376}