Preparation for E2E latency tuning #786

baranovmv · 2024-12-04T23:10:04Z

In order to be able to tune receiver's latency
relying on timestamp mapping that we get from
RTCP feedback, and UDP::Receive_timestamp,
adding these features:

RTCP improvements #674: Use receive timestamp (RTS) as report time when processing RTCP report;
RTT dumping for debugging (csvplotter ts_offset branch);
SCHED_RR for network io thread (run with root privs).

github-actions · 2025-01-16T12:19:01Z

🤖 The latest upstream change made this pull request unmergeable. Please resolve the merge conflicts.

gavv

Wow, this is big.

I like the approach you use for RTS (set early when possible, set later as a fallback).

src/internal_modules/roc_core/target_posix/roc_core/thread.cpp

src/tests/roc_rtcp/test_communicator.cpp

src/internal_modules/roc_netio/target_libuv/roc_netio/network_loop.cpp

src/internal_modules/roc_rtcp/rtt_estimator.h

gavv · 2025-01-16T17:26:12Z

src/internal_modules/roc_pipeline/sender_slot.cpp

+        if ((code = repair_endpoint_->pull_packets(0)) != status::StatusOK) {
            return code;
        }
    }


Same comment as for receiver slot.

I support your thought, but it will make pipeline tests dependent on real-time speed.

So far, LatencyMonitor calls core::timestamp(core::ClockUnix) when it computes latency_metrics_.niq_stalling. If we will set receive timestamp on all passing packets (which is your proposition here), we could not tell the difference between test and real use scenario. In order to pass these tests, I've set base_cts to current timestamp:

diff --git a/src/tests/roc_pipeline/test_loopback_sink_2_source.cpp b/src/tests/roc_pipeline/test_loopback_sink_2_source.cpp index 4c47930e..2d7e188c 100644 --- a/src/tests/roc_pipeline/test_loopback_sink_2_source.cpp +++ b/src/tests/roc_pipeline/test_loopback_sink_2_source.cpp @@ -569,7 +569,7 @@ void send_receive(int flags, core::nanoseconds_t virtual_e2e_latency = 0; if (flags & FlagCTS) { - send_base_cts = 1000000000000000; + send_base_cts = core::timestamp(core::ClockUnix); virtual_e2e_latency = core::Millisecond * 100; }

In receiver_source test latency_lower_bound I had to do the same.

Please, take a look onto 6bd629e

So, I propose to hold this change, until (if) we decide to introduce mock for core::timestamp(...) in pipeline tests.

Oh, I see. That's not good but I agree that it's outside of scope of this PR. I'll try to take a look at it later, will add it to my todo. Let's follow your proposal then.

I've reverted these changes for the time being

gavv · 2025-01-16T17:26:12Z

src/internal_modules/roc_pipeline/receiver_slot.cpp

+        if ((code = repair_endpoint_->pull_packets(0)) != status::StatusOK) {
            return code;
        }
    }


Since current_time is used only as a fallback when RTS isn't set, we can safely pass it to all calls I guess? Because why not to guarantee RTS for source and repair packets as well.

gavv · 2025-01-16T17:26:12Z

src/internal_modules/roc_rtcp/rtt_estimator.cpp

+    , last_report_ts_(0)
+    , dumper_(dumper)
+    , rtt_stats_(arena, 15, 0.5)
+    , clock_offset_stats_(arena, 100, 0.5) {


Please make this constants to be RttConfig fields with default values.

gavv · 2025-01-16T17:26:13Z

src/tests/roc_rtcp/test_communicator.cpp

 }

-// Same, but there is a persistent clock drift between sender and receiver
-TEST(communicator, rtt_clock_drift) {


If this test doesn't work due to smoothing of RTT, then we can disable smoothing specifically in this test by setting RttConfig fields (in some comment above I suggested to move smoothing settings to config).

gavv · 2025-01-16T17:41:12Z

In test_communicator.cpp, there are a several calls to read_packet() which provide timestamp argument, but that makes little sense.

Since it's receive timestamp, it has meaning only when we're "delivering" packet to a communicator (and it should correspond to it's "local" time). But in cases when we're reading packet just to inspect it and throw away, timestamp is not actually used and specifying it looks confusing IMHO.

Diff below removes timestamps that are not needed.

diff --git a/src/tests/roc_rtcp/test_communicator.cpp b/src/tests/roc_rtcp/test_communicator.cpp
index fbe1e0d5..227dd902 100644
--- a/src/tests/roc_rtcp/test_communicator.cpp
+++ b/src/tests/roc_rtcp/test_communicator.cpp
@@ -3107,7 +3107,7 @@ TEST(communicator, report_to_address_sender) {
     CHECK_EQUAL(1, send_comm.total_destinations());
     CHECK_EQUAL(1, send_queue.size());
 
-    pp = read_packet(send_queue, send_time);
+    pp = read_packet(send_queue);
     expect_has_dest_address(pp, send_dest_addr);
     expect_has_orig_ssrc(pp, SendSsrc, true);
     expect_has_dest_ssrc(pp, Recv1Ssrc, true);
@@ -3279,7 +3279,7 @@ TEST(communicator, report_back_sender) {
     CHECK_EQUAL(1, send_comm.total_destinations());
     CHECK_EQUAL(1, send_queue.size());
 
-    pp = read_packet(send_queue, send_time);
+    pp = read_packet(send_queue);
     expect_has_dest_address(pp, recv1_addr);
     expect_has_orig_ssrc(pp, SendSsrc, true);
     expect_has_dest_ssrc(pp, Recv1Ssrc, true);
@@ -3320,13 +3320,13 @@ TEST(communicator, report_back_sender) {
     CHECK_EQUAL(2, send_comm.total_destinations());
     CHECK_EQUAL(2, send_queue.size());
 
-    pp = read_packet(send_queue, send_time);
+    pp = read_packet(send_queue);
     expect_has_dest_address(pp, recv1_addr);
     expect_has_orig_ssrc(pp, SendSsrc, true);
     expect_has_dest_ssrc(pp, Recv1Ssrc, true);
     expect_has_dest_ssrc(pp, Recv2Ssrc, false);
 
-    pp = read_packet(send_queue, send_time);
+    pp = read_packet(send_queue);
     expect_has_dest_address(pp, recv2_addr);
     expect_has_orig_ssrc(pp, SendSsrc, true);
     expect_has_dest_ssrc(pp, Recv1Ssrc, false);
@@ -3423,7 +3423,7 @@ TEST(communicator, report_back_receiver) {
     CHECK_EQUAL(1, recv_comm.total_destinations());
     CHECK_EQUAL(1, recv_queue.size());
 
-    pp = read_packet(recv_queue, send1_time);
+    pp = read_packet(recv_queue);
     expect_has_dest_address(pp, send1_addr);
     expect_has_orig_ssrc(pp, RecvSsrc, true);
     expect_has_dest_ssrc(pp, Send1Ssrc, true);
@@ -3469,13 +3469,13 @@ TEST(communicator, report_back_receiver) {
     CHECK_EQUAL(2, recv_comm.total_destinations());
     CHECK_EQUAL(2, recv_queue.size());
 
-    pp = read_packet(recv_queue, recv_time);
+    pp = read_packet(recv_queue);
     expect_has_dest_address(pp, send1_addr);
     expect_has_orig_ssrc(pp, RecvSsrc, true);
     expect_has_dest_ssrc(pp, Send1Ssrc, true);
     expect_has_dest_ssrc(pp, Send2Ssrc, false);
 
-    pp = read_packet(recv_queue, recv_time);
+    pp = read_packet(recv_queue);
     expect_has_dest_address(pp, send2_addr);
     expect_has_orig_ssrc(pp, RecvSsrc, true);
     expect_has_dest_ssrc(pp, Send1Ssrc, false);
@@ -3606,14 +3606,14 @@ TEST(communicator, report_back_combine_reports) {
     CHECK_EQUAL(2, recv_comm.total_destinations());
     CHECK_EQUAL(2, recv_queue.size());
 
-    pp = read_packet(recv_queue, send3_time);
+    pp = read_packet(recv_queue);
     expect_has_dest_address(pp, send1_addr);
     expect_has_orig_ssrc(pp, RecvSsrc, true);
     expect_has_dest_ssrc(pp, Send1Ssrc, true);
     expect_has_dest_ssrc(pp, Send2Ssrc, true);
     expect_has_dest_ssrc(pp, Send3Ssrc, false);
 
-    pp = read_packet(recv_queue, send3_time);
+    pp = read_packet(recv_queue);
     expect_has_dest_address(pp, send3_addr);
     expect_has_orig_ssrc(pp, RecvSsrc, true);
     expect_has_dest_ssrc(pp, Send1Ssrc, false);
@@ -4269,7 +4269,7 @@ TEST(communicator, rtt_network_reordering) {
                 recv_reorder_countdown = ReorderBurst;
             }
             recv_reorder_countdown--;
-            packet::PacketPtr pp = read_packet(recv_queue, recv_time);
+            packet::PacketPtr pp = read_packet(recv_queue);
             recv_packet_stash.push_back(*pp);
         }

github-actions · 2025-02-07T04:13:36Z

🤖 The latest upstream change made this pull request unmergeable. Please resolve the merge conflicts.

In order to be able to tune receiver's latency relying on timestamp mapping that we get from RTCP feedback, and UDP::Receive_timestamp, adding these features: * roc-streaminggh-674: Use receive timestamp (RTS) as report time when processing RTCP report; * RTT dumping for debugging (csvplotter ts_offset branch); * SCHED_RR for network io thread (run with root privs).

src/tests/public_api/test_context.cpp src/tests/public_api/test_plugin_plc.cpp src/tests/public_api/test_sender.cpp src/tests/public_api/test_sender_encoder.cpp src/tests/public_api/test_version.cpp

rocstreaming-bot · 2025-06-05T16:05:34Z

🤖 Pull request is currently unmergeable due to conflicts.
Please rebase on up-to-date upstream branch, resolve merge conflicts, and force-push to pull request's branch. Remember to use rebase with force-push instead of a regular merge.

baranovmv requested a review from gavv December 4, 2024 23:10

github-actions bot added the S-ready-for-review status: PR can be reviewed label Dec 4, 2024

baranovmv force-pushed the feature/rtcp_rts branch 6 times, most recently from bc3295d to 99c8903 Compare December 12, 2024 17:25

baranovmv force-pushed the feature/rtcp_rts branch 2 times, most recently from a475567 to 5e85289 Compare December 19, 2024 21:41

github-actions bot added the S-needs-rebase status: PR has conflicts and should be rebased label Jan 16, 2025

gavv requested changes Jan 16, 2025

View reviewed changes

This comment was marked as duplicate.

Sign in to view

gavv added S-needs-revision status: Author should revise PR and address feedback and removed S-ready-for-review status: PR can be reviewed labels Jan 16, 2025

roc-streaming deleted a comment from MishaBaranov Feb 1, 2025

baranovmv force-pushed the feature/rtcp_rts branch from 7837ebe to 6bd629e Compare February 1, 2025 21:18

github-actions bot removed the S-needs-rebase status: PR has conflicts and should be rebased label Feb 1, 2025

baranovmv force-pushed the feature/rtcp_rts branch from 20a7b7a to 40c5dd5 Compare February 2, 2025 22:36

github-actions bot added the S-needs-rebase status: PR has conflicts and should be rebased label Feb 7, 2025

baranovmv force-pushed the feature/rtcp_rts branch from 40c5dd5 to 75a91d8 Compare February 9, 2025 18:13

github-actions bot removed the S-needs-rebase status: PR has conflicts and should be rebased label Feb 9, 2025

gavv added S-ready-for-review status: PR can be reviewed and removed S-needs-revision status: Author should revise PR and address feedback labels Feb 11, 2025

baranovmv added 2 commits February 12, 2025 22:48

remove some tests from public api

d0f9d22

src/tests/public_api/test_context.cpp src/tests/public_api/test_plugin_plc.cpp src/tests/public_api/test_sender.cpp src/tests/public_api/test_sender_encoder.cpp src/tests/public_api/test_version.cpp

baranovmv force-pushed the feature/rtcp_rts branch from c429757 to d0f9d22 Compare February 12, 2025 21:56

gavv added S-work-in-progress status: PR is still in progress and changing and removed S-ready-for-review status: PR can be reviewed labels Feb 20, 2025

baranovmv force-pushed the feature/rtcp_rts branch from 9a4fbfd to 516ed74 Compare March 18, 2025 21:49

Fix race in NetworkLoop

e211975

baranovmv force-pushed the feature/rtcp_rts branch from 516ed74 to e211975 Compare March 19, 2025 00:09

gavv added S-ready-for-review status: PR can be reviewed and removed S-work-in-progress status: PR is still in progress and changing labels Mar 23, 2025

rocstreaming-bot added the S-needs-rebase status: PR has conflicts and should be rebased label Jun 5, 2025

gavv added S-review-in-progress status: PR is being reviewed and removed S-ready-for-review status: PR can be reviewed labels Jun 18, 2025

Uh oh!

Preparation for E2E latency tuning #786

Are you sure you want to change the base?

Preparation for E2E latency tuning #786

Uh oh!

Conversation

baranovmv commented Dec 4, 2024

Uh oh!

github-actions bot commented Jan 16, 2025

Uh oh!

gavv left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gavv Jan 16, 2025

Choose a reason for hiding this comment

Uh oh!

baranovmv Feb 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

baranovmv Feb 1, 2025

Choose a reason for hiding this comment

Uh oh!

gavv Feb 5, 2025

Choose a reason for hiding this comment

Uh oh!

baranovmv Feb 9, 2025

Choose a reason for hiding this comment

Uh oh!

gavv Jan 16, 2025

Choose a reason for hiding this comment

Uh oh!

gavv Jan 16, 2025

Choose a reason for hiding this comment

Uh oh!

gavv Jan 16, 2025

Choose a reason for hiding this comment

Uh oh!

This comment was marked as duplicate.

Uh oh!

gavv commented Jan 16, 2025

Uh oh!

github-actions bot commented Feb 7, 2025

Uh oh!

rocstreaming-bot commented Jun 5, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

baranovmv Feb 1, 2025 •

edited

Loading