Several Tick counter improvements try #2."

Several Tick counter improvements try #2."

This reverts commit c91d1738709b038fee84d569180cba2bbcbfe5d7.

BUG=

Committed: https://crrev.com/2935e0141939adc642d73da6d8048a4e918a8382
Cr-Commit-Position: refs/heads/master@{#10682}

[noahric, 2015-11-17 19:34:58]

noahric@chromium.org changed reviewers:
+ noahric@chromium.org

[noahric, 2015-11-17 19:34:59]

lgtm

[pbos-webrtc, 2015-11-17 21:35:34]

On 2015/11/17 19:34:59, noahric wrote:
> lgtm

lgtm but please link to the CL you're relanding instead of saying what hash you
reverted. (And you can put TBR=mflodman@webrtc.org for the re-land)

[pbos-webrtc, 2015-11-17 21:36:50]

Description was changed from

==========
Several Tick counter improvements try #2."

This reverts commit c91d1738709b038fee84d569180cba2bbcbfe5d7.

BUG=
==========

to

==========
Several Tick counter improvements try #2."

This reverts commit c91d1738709b038fee84d569180cba2bbcbfe5d7.

BUG=
==========

[pbos-webrtc, 2015-11-17 21:36:50]

pbos@webrtc.org changed reviewers:
+ mflodman@webrtc.org, pbos@webrtc.org

[mflodman, 2015-11-17 21:45:59]

LGTM

[thaloun, 2015-11-17 22:00:13]

The CQ bit was checked by thaloun@chromium.org

[commit-bot: I haz the power, 2015-11-17 22:00:16]

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

[commit-bot: I haz the power, 2015-11-17 23:02:55]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-11-17 23:03:08]

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

[tommi, 2016-01-23 14:09:41]

tommi@webrtc.org changed reviewers:
+ tommi@webrtc.org

[tommi, 2016-01-23 14:09:41]

https://codereview.webrtc.org/1452843003/diff/1/webrtc/system_wrappers/source...
File webrtc/system_wrappers/source/tick_util.cc (right):

https://codereview.webrtc.org/1452843003/diff/1/webrtc/system_wrappers/source...
webrtc/system_wrappers/source/tick_util.cc:140: return mach_absolute_time() -
timebase_start;
There's a bug here which will affect cases where Random() is initialized with a
seed derived from this implementation.

Since the tick count can be very low, conversion over to microseconds, can yield
0.  Atm Random will dcheck in debug builds due to this, but even when it
doesn't, I think that the randomness of the seed is reduced by this
implementation.

[noahric, 2016-01-25 21:58:48]

On 2016/01/23 14:09:41, tommi-webrtc wrote:
>
https://codereview.webrtc.org/1452843003/diff/1/webrtc/system_wrappers/source...
> File webrtc/system_wrappers/source/tick_util.cc (right):
> 
>
https://codereview.webrtc.org/1452843003/diff/1/webrtc/system_wrappers/source...
> webrtc/system_wrappers/source/tick_util.cc:140: return mach_absolute_time() -
> timebase_start;
> There's a bug here which will affect cases where Random() is initialized with
a
> seed derived from this implementation.
> 
> Since the tick count can be very low, conversion over to microseconds, can
yield
> 0.  Atm Random will dcheck in debug builds due to this, but even when it
> doesn't, I think that the randomness of the seed is reduced by this
> implementation.

Agreed, I bet that will significantly impact randomness relative to the old
implementation, though the API sorta calls out that this kind of thing is
possible (" Return a timestamp in microseconds relative to some arbitrary
source"). Do you think it's sufficient to take the three places that seed a
webrtc/base/random with the time in micros function?
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc...

We could expose an int64_t GetTicks, though it strictly speaking would have the
same issue. Ticks relative to "some arbitrary point" could pick points the same
way this implementation did for time (first time asked).