Context: The timer precision of PostDelayedTask() is about to be lowered
to include up to 17 ms leeway. In order not to break use cases that
require high precision timers, PostDelayedHighPrecisionTask() will
continue to have the same precision that PostDelayedTask() has today.
webrtc::TaskQueueBase has an enum (kLow, kHigh) to decide which
precision to use when calling PostDelayedTaskWithPrecision().
See go/postdelayedtask-precision-in-webrtc for motivation and a table of
delayed task use cases in WebRTC that are "high" or "low" precision.
Most timers in DCSCTP are believed to only be needing low precision (see
table), but the delayed_ack_timer_ of DataTracker[1] is an example of a
use case that is likely to break if the timer precision is lowered (if
ACK is sent too late, retransmissions may occur). So this is considered
a high precision use case.
This CL makes it possible to specify the precision of dcsctp::Timer.
In a follow-up CL we will update delayed_ack_timer_ to kHigh precision.
[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/net/dcsctp/rx/data_tracker.cc;l=340
Bug: webrtc:13604
Change-Id: I8eec5ce37044096978b5dd1985fbb00bc0d8fb7e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249081
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35809}
Networks tests were previously disabled if building in debug mode as
debug mode adds DCHECKs, and when DCHECKs are enabled, a lot of the
components in dcSCTP will add consistency checks, and they can be really
expensive to run in these network tests.
However, if running in with TSAN or MSAN sanitizers and with DCHECKs
enabled, they also take a long time.
Current run-time on my relatively fast CPU (with is_debug=false):
(no sanitizer) always_dcheck=false: 2.5s
(no sanitizer) always_dcheck=true: 31s
is_tsan=true, always_dcheck=false: 53s
is_tsan=true, always_dcheck=true: 5m50s <-- too slow
is_asan=true, always_dcheck=false: 13s
is_asan=true, always_dcheck=true: 47s
is_msan=true, always_dcheck=false: 35s
is_msan=true, always_dcheck=true: 1m53s <-- too slow
Note that buildbots may be much slower than my computer.
Bug: webrtc:12943
Change-Id: If044ee9936372d54c9899b4864156c9f680af0b6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236581
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35276}
This initial version contains a few tests, testing both lossy, non-lossy
and bandwidth limited networks. It uses simulated time, and runs much
faster than wall time on release builds, but slower on debug when there
is a lot of outstanding data (high throughput) as there are consistency
checks on outstanding data. Because of that, some tests had to be
disabled in debug build.
Bug: webrtc:12943
Change-Id: I9323f2dc99bca4e40558d05a283e99ce7dded7f1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225201
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35124}
