Re: [RFC PATCH v6 00/25] Hierarchical Constant Bandwidth Server

From: Juri Lelli

Date: Wed Jun 24 2026 - 06:35:34 EST


Hi Luca,

On 24/06/26 09:19, luca abeni wrote:
> Hi Juri,
>
> very interesting demo, thanks!
>
> On Tue, 23 Jun 2026 12:15:08 +0200
> Juri Lelli <juri.lelli@xxxxxxxxxx> wrote:
> [...]
> > - At 1ms task periods, the dl-server period is the critical tuning
> > parameter, less the bandwidth. A 10ms dl-server with 60% bandwidth
> > caused ~10% miss rates because the worst-case throttle gap (4ms)
> > spanned multiple 1ms deadlines. Switching to a 2ms dl-server period
> > at just 30% bandwidth eliminated all misses.
> >
> > - A simple Rule of thumb might be to set the dl-server period to at
> > most 2x the shortest task period in the cgroup (e.g., 2ms dl-server
> > for 1ms tasks, 10ms for 10ms tasks). Would you (and Luca?) agree or
> > would you suggest something different?
>
> With one single RT task in the cgroup (or with multiple synchronized RT
> tasks having the same period), I agree... Technically, the cgroup period
> P should be such that P - Q = T - WCET (where "Q" is the cgroup's
> runtime and "T" is the period of the task), but to see missed deadlines
> you need a relevant competing deadline (or HCBS) workload.
>
> So, yes, I agree with your findings above.

Great, thanks a lot for taking a look!

> If we consider multi-core analysis, or multiple RT threads with
> different, non synchronized, periods, then analysis tool by Yuri
> (leveraging CSF analysis from real-time literature) is needed... But
> that is pretty pessimistic. The rule you suggest above is a better
> starting point in practical situations.

Indeed. I actually wonder if it would make sense to "extract" that tool
from the test suite and package it somehow so that it's easier for end
users to design their interfaces.

Best,
Juri