Preparation for E2E latency tuning by baranovmv · Pull Request #786 · roc-streaming/roc-toolkit

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).

gavv

Wow, this is big.

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

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

+        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

It was actually very easy fix: 05ab131

baranovmv · 2026-01-16T23:37:43Z

@gavv "No conflicts with base branch" -- no excuses to not merge it?

I removed the commit where I deleted public-api tests, don't remember reason for that to exist.

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).

1. Don't use LogError in utility code because only upper layer decides if it's actually an error. 2. Remove StatusFailedRealtime, we already have StatusErrThread for thread setup failures. 3. Rename capture_ts -> receive_ts for consistency. 4. Cleanup log messages, log levels, typos.

Bare parameters don't scale well - tests already became polluted with DEFAULT_PRIORITY, adding more params will add more noise. So introduce the usual config struct for NetworkLoop and replace DEFAULT_PRIORITY with default value of its field.

Similar to NetworkConfig::realtime_prio, add IoConfig::realtime_prio.

Add new group "Perf options" and move --real-time flag there.

Pass current time from pipeline to from refresh(), called before every frame read. Integration tests already pass virtual time to pipeline refresh(), so LatencyMonitor automatically starts working with proper time.

gavv · 2026-08-24T15:51:50Z

LGTM, rebased on fresh develop & pushed a few refactorings & fixes:

8d275bf, 031db3d - cosmetics
2e8f8a4, 089a7f0 - move rt priority to config structs
05ab131 - virtual time in tests

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

This comment was marked as resolved.

Sign in to view

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

This comment was marked as resolved.

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

This comment was marked as resolved.

Sign in to view

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 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 2 times, most recently 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

This comment was marked as resolved.

Sign in to view

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

baranovmv force-pushed the feature/rtcp_rts branch from e211975 to 2bf7513 Compare January 16, 2026 22:55

rocstreaming-bot removed the S-needs-rebase status: PR has conflicts and should be rebased label Jan 16, 2026

baranovmv added 2 commits August 24, 2026 23:03

roc-streaminggh-127: Fix race in NetworkLoop

74eb518

gavv force-pushed the feature/rtcp_rts branch from 2bf7513 to a388bda Compare August 24, 2026 13:03

gavv added 4 commits August 24, 2026 23:52

roc-streaminggh-127: Move realtime_prio from IoPump::run() to IoConfig

9e524d4

Similar to NetworkConfig::realtime_prio, add IoConfig::realtime_prio.

roc-streaminggh-127: Put --real-time arg in new group

e97d6c7

Add new group "Perf options" and move --real-time flag there.

gavv added this to the 0.5.0 milestone Aug 24, 2026

roc-streaminggh-127: Untie LatencyMonitor from real time

39f07d9

Pass current time from pipeline to from refresh(), called before every frame read. Integration tests already pass virtual time to pipeline refresh(), so LatencyMonitor automatically starts working with proper time.

rocstreaming-bot added S-needs-revision status: Author should revise PR and address feedback and removed S-review-in-progress status: PR is being reviewed labels Aug 24, 2026

gavv removed the S-needs-revision status: Author should revise PR and address feedback label Aug 24, 2026

gavv force-pushed the feature/rtcp_rts branch from 05ab131 to 39f07d9 Compare August 24, 2026 16:27

gavv merged commit 9cfc616 into roc-streaming:develop Aug 24, 2026
47 checks passed

Uh oh!

Uh oh!

Conversation

baranovmv commented Dec 4, 2024 • edited by gavv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as resolved.

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 Aug 24, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment was marked as duplicate.

Uh oh!

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

baranovmv commented Jan 16, 2026

Uh oh!

gavv commented Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

baranovmv commented Dec 4, 2024 •

edited by gavv

Loading

baranovmv Feb 1, 2025 •

edited

Loading

gavv commented Aug 24, 2026 •

edited

Loading