Read recv timestamps from socket (posix only).

Read recv timestamps from socket (posix only).

This helps a lot on Android devices where the user threads can be scheduled with low priority when the app is in the background, causing spurious significantly delayed before a packet can be read from the socket. With this patch the timestamp is taken by the kernel when the packet actually arrives.

R=juberti@chromium.org
TBR=juberti@webrtc.org

BUG=webrtc:5773
Committed: https://chromium.googlesource.com/external/webrtc/+/9131efdb30f2ad37e252ace2c5fcd65fdef288f5

[stefan-webrtc, 2016-05-03 11:05:59]

Description was changed from

==========
Read recv timestamps from socket (posix only).

BUG=webrtc:5773
==========

to

==========
Read recv timestamps from socket (posix only).

This helps a lot on Android devices where the user threads can be scheduled with
low priority when the app is in the background, causing spurious significantly
delayed before a packet can be read from the socket. With this patch the
timestamp is taken by the kernel when the packet actually arrives.

BUG=webrtc:5773
==========

[stefan-webrtc, 2016-05-03 11:07:40]

Cleanup

[stefan-webrtc, 2016-05-03 11:08:20]

Cleanup 2.

[stefan-webrtc, 2016-05-03 11:10:25]

stefan@webrtc.org changed reviewers:
+ pthatcher@webrtc.org

[stefan-webrtc, 2016-05-03 11:10:33]

The CQ bit was checked by stefan@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-03 11:10:42]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1944683002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1944683002/40001

[commit-bot: I haz the power, 2016-05-03 11:12:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-03 11:12:32]

Dry run: Try jobs failed on following builders:
  ios64_sim_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios64_sim_dbg/builds/7168)
  ios_arm64_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_arm64_dbg/builds/9505)
  ios_arm64_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_arm64_rel/builds/9430)
  ios_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_rel/builds/13362)
  mac_gn_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_gn_rel/builds/9074)

[stefan-webrtc, 2016-05-03 11:51:40]

Fix build.

[stefan-webrtc, 2016-05-03 12:07:10]

Fix win build.

[stefan-webrtc, 2016-05-03 12:14:38]

The CQ bit was checked by stefan@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-03 12:14:48]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1944683002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1944683002/80001

[commit-bot: I haz the power, 2016-05-03 14:15:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-03 14:15:54]

Dry run: Try jobs failed on following builders:
  android_arm64_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_dbg on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[stefan-webrtc, 2016-05-05 14:49:50]

It would be great to get this reviewed, as it's something we really want to get
in.

[juberti2, 2016-05-10 16:49:24]

juberti@chromium.org changed reviewers:
+ juberti@google.com

[juberti2, 2016-05-11 05:03:33]

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

[juberti2, 2016-05-11 05:03:34]

Overall LG
Needs unit test in physicalsocketserver_unittest

https://codereview.webrtc.org/1944683002/diff/80001/webrtc/base/physicalsocke...
File webrtc/base/physicalsocketserver.cc (right):

https://codereview.webrtc.org/1944683002/diff/80001/webrtc/base/physicalsocke...
webrtc/base/physicalsocketserver.cc:65: int ret = ioctl(socket, SIOCGSTAMP,
&tv_ioctl);
Do you need to set a socket option for this to work?

https://codereview.webrtc.org/1944683002/diff/80001/webrtc/base/physicalsocke...
webrtc/base/physicalsocketserver.cc:362: *timestamp =
GetSocketRecvTimestamp(s_);
Allow NULL to be passed so that clients who don't care about timestamps don't
have to write more complex code.

[stefan-webrtc, 2016-05-11 08:11:43]

Comments addressed.

[stefan-webrtc, 2016-05-11 08:30:17]

Improve test.

[stefan-webrtc, 2016-05-11 08:30:45]

The CQ bit was checked by stefan@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-11 08:30:53]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1944683002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1944683002/120001

[commit-bot: I haz the power, 2016-05-11 08:40:44]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-11 08:40:45]

Dry run: Try jobs failed on following builders:
  android_compile_x86_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_compile_x86_dbg...)

[stefan-webrtc, 2016-05-11 08:41:14]

I added a timestamp verification in TestClient used by all the unittests for
PhysicalSocketServer.

https://codereview.webrtc.org/1944683002/diff/80001/webrtc/base/physicalsocke...
File webrtc/base/physicalsocketserver.cc (right):

https://codereview.webrtc.org/1944683002/diff/80001/webrtc/base/physicalsocke...
webrtc/base/physicalsocketserver.cc:65: int ret = ioctl(socket, SIOCGSTAMP,
&tv_ioctl);
On 2016/05/11 05:03:34, juberti2 wrote:
> Do you need to set a socket option for this to work?

No. There are two ways of getting the timestamp from the socket
1) this way which doesn't require a socket option
2) reading the timestamp with recvmsg(), which requires setting the
SO_TIMESTAMPING socket option. Doing that also disables the first way of reading
recv timestamps.

#1 is a lot simpler, so I suggest going with that for now at least.

https://codereview.webrtc.org/1944683002/diff/80001/webrtc/base/physicalsocke...
webrtc/base/physicalsocketserver.cc:362: *timestamp =
GetSocketRecvTimestamp(s_);
On 2016/05/11 05:03:34, juberti2 wrote:
> Allow NULL to be passed so that clients who don't care about timestamps don't
> have to write more complex code.

Done.

[juberti2, 2016-05-11 19:57:22]

LG once unit testing is sufficient

https://codereview.webrtc.org/1944683002/diff/120001/webrtc/base/testclient.cc
File webrtc/base/testclient.cc (right):

https://codereview.webrtc.org/1944683002/diff/120001/webrtc/base/testclient.c...
webrtc/base/testclient.cc:96: (prev_packet_timestamp_ == -1 ||
I think that -1 should only be allowed when we know no timestamps are available.
For example, in the UdpInternal test, we should fail if we get -1 on a supported
platform.

We should also check this against our own Time() clock somehow - perhaps by
adding a new CheckNextPacketWithTime method that allows an external time to be
passed in (which would be used in the UdpInternal test).

[stefan-webrtc, 2016-05-12 09:13:12]

Improve tests.

[stefan-webrtc, 2016-05-12 09:15:20]

The CQ bit was checked by stefan@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-12 09:15:29]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1944683002/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1944683002/140001

[commit-bot: I haz the power, 2016-05-12 09:22:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-12 09:22:18]

Dry run: Try jobs failed on following builders:
  android_compile_x86_dbg on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/android_compile_x86_dbg...)

[stefan-webrtc, 2016-05-12 11:18:55]

Add tests to more extensively ensure timestamps work over a longer interval.

[stefan-webrtc, 2016-05-12 11:19:53]

I added a test which ensures that the timestamps are right for a longer interval
(5 seconds) in patchset 8.

https://codereview.webrtc.org/1944683002/diff/120001/webrtc/base/testclient.cc
File webrtc/base/testclient.cc (right):

https://codereview.webrtc.org/1944683002/diff/120001/webrtc/base/testclient.c...
webrtc/base/testclient.cc:96: (prev_packet_timestamp_ == -1 ||
On 2016/05/11 19:57:22, juberti2 wrote:
> I think that -1 should only be allowed when we know no timestamps are
available.
> For example, in the UdpInternal test, we should fail if we get -1 on a
supported
> platform.


We don't expect -1 to be returned on any platform since we fall back to system
time if the socket doesn't provide us with a timestamp. I'll verify that though.

> 
> We should also check this against our own Time() clock somehow - perhaps by
> adding a new CheckNextPacketWithTime method that allows an external time to be
> passed in (which would be used in the UdpInternal test).

This should also be possible to check on all platforms since we have the
fallback. I'm now comparing deltas between two packets to avoid issues where the
socket timestamp has a different epoch than our own time implementation.

[stefan-webrtc, 2016-05-12 11:21:16]

The CQ bit was checked by stefan@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-12 11:21:28]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1944683002/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1944683002/160001

[commit-bot: I haz the power, 2016-05-12 11:30:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-12 11:30:02]

Dry run: Try jobs failed on following builders:
  linux_asan on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_asan/builds/14643)

[stefan-webrtc, 2016-05-16 08:17:37]

More robust tests.

[stefan-webrtc, 2016-05-16 08:19:58]

The CQ bit was checked by stefan@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-16 08:20:08]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1944683002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1944683002/180001

[commit-bot: I haz the power, 2016-05-16 08:31:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-16 08:31:30]

Dry run: Try jobs failed on following builders:
  linux_asan on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_asan/builds/14721)

[stefan-webrtc, 2016-05-16 12:07:40]

Disable ipv6 test on Linux due to bot issues.

[stefan-webrtc, 2016-05-16 12:07:59]

The CQ bit was checked by stefan@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-16 12:08:03]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1944683002/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1944683002/200001

[stefan-webrtc, 2016-05-16 13:00:02]

Justin, could you take another look at this?

[commit-bot: I haz the power, 2016-05-16 14:08:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-16 14:08:34]

Dry run: Try jobs failed on following builders:
  android_arm64_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[juberti2, 2016-05-17 06:41:35]

On 2016/05/12 11:19:53, stefan-webrtc (holmer) wrote:
> I added a test which ensures that the timestamps are right for a longer
interval
> (5 seconds) in patchset 8.
> 
> https://codereview.webrtc.org/1944683002/diff/120001/webrtc/base/testclient.cc
> File webrtc/base/testclient.cc (right):
> 
>
https://codereview.webrtc.org/1944683002/diff/120001/webrtc/base/testclient.c...
> webrtc/base/testclient.cc:96: (prev_packet_timestamp_ == -1 ||
> On 2016/05/11 19:57:22, juberti2 wrote:
> > I think that -1 should only be allowed when we know no timestamps are
> available.
> > For example, in the UdpInternal test, we should fail if we get -1 on a
> supported
> > platform.
> 
> 
> We don't expect -1 to be returned on any platform since we fall back to system
> time if the socket doesn't provide us with a timestamp. I'll verify that
though.

I didn't follow this comment - won't -1 be returned on all platforms except
Linux/Android?

> > 
> > We should also check this against our own Time() clock somehow - perhaps by
> > adding a new CheckNextPacketWithTime method that allows an external time to
be
> > passed in (which would be used in the UdpInternal test).
> 
> This should also be possible to check on all platforms since we have the
> fallback. I'm now comparing deltas between two packets to avoid issues where
the
> socket timestamp has a different epoch than our own time implementation.

But I think this case is what you need to test for - don't we want to ensure
that the socket timestamp is from a clock that we understand? Otherwise, how can
we compare it to our own clock?

I would also prefer not to have a test that runs for 5 seconds - it should be
possible to measure that timestamps are increasing properly in a shorter test.
Overall I think you want the test to verify that a) timestamps are not -1, b)
packet times increase in successive packets, c) packet times increase by about
the right amount, and d) packet times increase similarly to our own clock.

[juberti2, 2016-05-17 06:41:49]

https://codereview.webrtc.org/1944683002/diff/200001/webrtc/base/physicalsock...
File webrtc/base/physicalsocketserver_unittest.cc (right):

https://codereview.webrtc.org/1944683002/diff/200001/webrtc/base/physicalsock...
webrtc/base/physicalsocketserver_unittest.cc:452:
SocketTest::TestUdpIpv6Interval();
Isn't this handled in socket_unittest already?

[stefan-webrtc, 2016-05-17 07:34:15]

On 2016/05/17 06:41:35, juberti2 wrote:
> On 2016/05/12 11:19:53, stefan-webrtc (holmer) wrote:
> > I added a test which ensures that the timestamps are right for a longer
> interval
> > (5 seconds) in patchset 8.
> > 
> >
https://codereview.webrtc.org/1944683002/diff/120001/webrtc/base/testclient.cc
> > File webrtc/base/testclient.cc (right):
> > 
> >
>
https://codereview.webrtc.org/1944683002/diff/120001/webrtc/base/testclient.c...
> > webrtc/base/testclient.cc:96: (prev_packet_timestamp_ == -1 ||
> > On 2016/05/11 19:57:22, juberti2 wrote:
> > > I think that -1 should only be allowed when we know no timestamps are
> > available.
> > > For example, in the UdpInternal test, we should fail if we get -1 on a
> > supported
> > > platform.
> > 
> > 
> > We don't expect -1 to be returned on any platform since we fall back to
system
> > time if the socket doesn't provide us with a timestamp. I'll verify that
> though.
> 
> I didn't follow this comment - won't -1 be returned on all platforms except
> Linux/Android?

The -1 you see in the test is just part of the test to separate the case when
the very first packet is received and we don't have a previous packet
(prev_packet_timestamp_) to compare with from the other cases. We already handle
the case where GetSocketRecvTimestamp() returns -1 as we check for that in
asyncudpsocket.cc and generate our own timestamp if it failed:
timestamp > -1 ? PacketTime(timestamp, 0) : CreatePacketTime(0)

I think that's preferable since we do want to get a timestamp as close to the
socket as possible even if the physical socket itself doesn't provide one.

> 
> > > 
> > > We should also check this against our own Time() clock somehow - perhaps
by
> > > adding a new CheckNextPacketWithTime method that allows an external time
to
> be
> > > passed in (which would be used in the UdpInternal test).
> > 
> > This should also be possible to check on all platforms since we have the
> > fallback. I'm now comparing deltas between two packets to avoid issues where
> the
> > socket timestamp has a different epoch than our own time implementation.
> 
> But I think this case is what you need to test for - don't we want to ensure
> that the socket timestamp is from a clock that we understand? Otherwise, how
can
> we compare it to our own clock?

Our BWE doesn't care about absolute timestamps since it only uses timestamp
deltas. The important thing from a BWE point of view is that we're getting
microsecond timestamps that aren't drifting too much from the sender's system
clock.

> 
> I would also prefer not to have a test that runs for 5 seconds - it should be
> possible to measure that timestamps are increasing properly in a shorter test.
> Overall I think you want the test to verify that a) timestamps are not -1, b)
> packet times increase in successive packets, c) packet times increase by about
> the right amount, and d) packet times increase similarly to our own clock.

I can rewrite TestClient::CheckTimestamp() to achieve all of this except the -1
check (since we never get -1, see above) and simply rely on
PhysicalSocketTest.TestUdpIPv4. Is that a good enough solution?

If we really want to check for -1 we can change the implementation and move out
the -1 check mentioned above to the listeners attached to SignalReadPacket, but
that will mean code duplication and other issues, so I'm not super keen on that.
Or maybe we write a unittest directly on PhysicalSocket, but I couldn't find any
unittests at that level. Should I look into adding one?

[stefan-webrtc, 2016-05-17 09:44:49]

Adds a better test to verify the timestamp is set.

[stefan-webrtc, 2016-05-17 10:26:07]

The CQ bit was checked by stefan@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-17 10:26:16]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1944683002/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1944683002/220001

[commit-bot: I haz the power, 2016-05-17 10:40:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-17 10:40:58]

Dry run: Try jobs failed on following builders:
  mac_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_rel/builds/15176)

[stefan-webrtc, 2016-05-17 10:43:52]

Don't run test on Mac.

[stefan-webrtc, 2016-05-17 10:47:33]

Fix mem leak.

[stefan-webrtc, 2016-05-17 10:48:12]

The CQ bit was checked by stefan@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-17 10:48:24]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1944683002/260001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1944683002/260001

[stefan-webrtc, 2016-05-17 11:33:33]

I went with the approach of testing on a Socket directly, without using
AsyncSocket. That way I can check the returned timestamp more easily and verify
that it's > -1.

I still don't compare the return timestamp with our own clock since our clock
measures time from when the system booted, while the socket gives us the time
since the unix epoch. As mentioned before, it doesn't really matter for BWE. I
could compare the timestamp with gettimeofday(), but I don't think it's that
meaningful.

I decided to keep the TestClient::CheckTimestamp() code, but I'd be ok with
removing it if we think this new test provides enough coverage. The former
however also tests the AsyncSocket path and verifies that a reasonable timestamp
is provided on all platforms, even if the socket provides a timestamp.

[commit-bot: I haz the power, 2016-05-17 12:59:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-17 12:59:30]

Dry run: This issue passed the CQ dry run.

[juberti2, 2016-05-18 06:09:41]

On 2016/05/17 11:33:33, stefan-webrtc (holmer) wrote:
> I went with the approach of testing on a Socket directly, without using
> AsyncSocket. That way I can check the returned timestamp more easily and
verify
> that it's > -1.
> 
> I still don't compare the return timestamp with our own clock since our clock
> measures time from when the system booted, while the socket gives us the time
> since the unix epoch. As mentioned before, it doesn't really matter for BWE. I
> could compare the timestamp with gettimeofday(), but I don't think it's that
> meaningful.
> 
> I decided to keep the TestClient::CheckTimestamp() code, but I'd be ok with
> removing it if we think this new test provides enough coverage. The former
> however also tests the AsyncSocket path and verifies that a reasonable
timestamp
> is provided on all platforms, even if the socket provides a timestamp.

OK. I didn't get a chance to look at this today with I/O prep, but will take
another look Weds.

[stefan-webrtc, 2016-05-19 12:53:49]

On 2016/05/18 06:09:41, juberti2 wrote:
> On 2016/05/17 11:33:33, stefan-webrtc (holmer) wrote:
> > I went with the approach of testing on a Socket directly, without using
> > AsyncSocket. That way I can check the returned timestamp more easily and
> verify
> > that it's > -1.
> > 
> > I still don't compare the return timestamp with our own clock since our
clock
> > measures time from when the system booted, while the socket gives us the
time
> > since the unix epoch. As mentioned before, it doesn't really matter for BWE.
I
> > could compare the timestamp with gettimeofday(), but I don't think it's that
> > meaningful.
> > 
> > I decided to keep the TestClient::CheckTimestamp() code, but I'd be ok with
> > removing it if we think this new test provides enough coverage. The former
> > however also tests the AsyncSocket path and verifies that a reasonable
> timestamp
> > is provided on all platforms, even if the socket provides a timestamp.
> 
> OK. I didn't get a chance to look at this today with I/O prep, but will take
> another look Weds.

Reminder to review this on Thursday, thanks!

[juberti2, 2016-05-23 06:19:36]

lgtm

Go ahead and land this - my comments are pretty minor, and can be addressed in a
followup CL.

[stefan-webrtc, 2016-05-23 13:33:56]

The CQ bit was checked by stefan@webrtc.org

[commit-bot: I haz the power, 2016-05-23 13:34:03]

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

[commit-bot: I haz the power, 2016-05-23 13:44:45]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-23 13:44:47]

Try jobs failed on following builders:
  presubmit on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/presubmit/builds/5756)

[stefan-webrtc, 2016-05-23 13:50:05]

Justin, I need an lgtm from your webrtc.org account.

[stefan-webrtc, 2016-05-23 15:38:55]

Description was changed from

==========
Read recv timestamps from socket (posix only).

This helps a lot on Android devices where the user threads can be scheduled with
low priority when the app is in the background, causing spurious significantly
delayed before a packet can be read from the socket. With this patch the
timestamp is taken by the kernel when the packet actually arrives.

BUG=webrtc:5773
==========

to

==========
Read recv timestamps from socket (posix only).

This helps a lot on Android devices where the user threads can be scheduled with
low priority when the app is in the background, causing spurious significantly
delayed before a packet can be read from the socket. With this patch the
timestamp is taken by the kernel when the packet actually arrives.

TBR=juberti@webrtc.org

BUG=webrtc:5773
==========

[stefan-webrtc, 2016-05-23 15:39:06]

The CQ bit was checked by stefan@webrtc.org

[commit-bot: I haz the power, 2016-05-23 15:39:14]

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

[commit-bot: I haz the power, 2016-05-23 16:19:46]

Description was changed from

==========
Read recv timestamps from socket (posix only).

This helps a lot on Android devices where the user threads can be scheduled with
low priority when the app is in the background, causing spurious significantly
delayed before a packet can be read from the socket. With this patch the
timestamp is taken by the kernel when the packet actually arrives.

TBR=juberti@webrtc.org

BUG=webrtc:5773
==========

to

==========
Read recv timestamps from socket (posix only).

This helps a lot on Android devices where the user threads can be scheduled with
low priority when the app is in the background, causing spurious significantly
delayed before a packet can be read from the socket. With this patch the
timestamp is taken by the kernel when the packet actually arrives.

R=juberti@chromium.org
TBR=juberti@webrtc.org

BUG=webrtc:5773

Committed: https://crrev.com/9131efdb30f2ad37e252ace2c5fcd65fdef288f5
Cr-Commit-Position: refs/heads/master@{#12850}
==========

[stefan-webrtc, 2016-05-23 16:19:47]

Description was changed from

==========
Read recv timestamps from socket (posix only).

This helps a lot on Android devices where the user threads can be scheduled with
low priority when the app is in the background, causing spurious significantly
delayed before a packet can be read from the socket. With this patch the
timestamp is taken by the kernel when the packet actually arrives.

R=juberti@chromium.org
TBR=juberti@webrtc.org

BUG=webrtc:5773

Committed: https://crrev.com/9131efdb30f2ad37e252ace2c5fcd65fdef288f5
Cr-Commit-Position: refs/heads/master@{#12850}
==========

to

==========
Read recv timestamps from socket (posix only).

This helps a lot on Android devices where the user threads can be scheduled with
low priority when the app is in the background, causing spurious significantly
delayed before a packet can be read from the socket. With this patch the
timestamp is taken by the kernel when the packet actually arrives.

R=juberti@chromium.org
TBR=juberti@webrtc.org

BUG=webrtc:5773

Committed:
https://chromium.googlesource.com/external/webrtc/+/9131efdb30f2ad37e252ace2c...
==========

[commit-bot: I haz the power, 2016-05-23 16:19:48]

Patchset 15 (id:??) landed as
https://crrev.com/9131efdb30f2ad37e252ace2c5fcd65fdef288f5
Cr-Commit-Position: refs/heads/master@{#12850}

[stefan-webrtc, 2016-05-23 16:19:49]

Committed patchset #15 (id:280001) manually as
9131efdb30f2ad37e252ace2c5fcd65fdef288f5 (presubmit successful).