> 1) Since we're still duking it out over the meaning of the bits - not
> just the SCE thing, but as best as I can
> tell (but could be wrong) the NQB idea wants to put something into the
> l4s fast queue? Or is NQB supposed to
> be a third queue?
We can add support for NQB in the future, by
From: Olga Albisser
DualPI2 provides L4S-type low latency & loss to traffic that uses a
scalable congestion controller (e.g. TCP-Prague, DCTCP) without
degrading the performance of 'classic' traffic (e.g. Reno,
Cubic etc.). It is intended to be the reference implementation of the
IETF's DualQ
> +static s64 __scale_delta(s64 diff)
> +{
> + do_div(diff, (1 << (ALPHA_BETA_GRANULARITY + 1)) - 1);
> + return diff;
> +}
[...]
> + delta = __scale_delta(((s64)qdelay - q->pi2.target) * q->pi2.alpha);
> + delta += __scale_delta(((s64)qdelay - qdelay_old) * q->pi2.beta);
I just
From: Olga Albisser
DualPI2 provides L4S-type low latency & loss to traffic that uses a
scalable congestion controller (e.g. TCP-Prague, DCTCP) without
degrading the performance of 'classic' traffic (e.g. Reno,
Cubic etc.). It is intended to be the reference implementation of the
IETF's DualQ
> DCTCP is meant to be used in environments where the switches/routers do
> ECN marking, so it is not surprising that it performs badly when used in
> environments where it was not meant to be used. Has anyone measured the
> effect of this changed when DCTCP is used in environments where all the
>
RFC8257 ยง3.5 explicitly states that DCTCP should "react to loss
episode in the same way that a conventional TCP".
This is also the behavior on MS Windows.
Currently, Linux DCTCP performs no ssthresh reduction when losses
are encountered. Optionally, the dctcp_clamp_alpha_on_loss resets
alpha to
6 matches
Mail list logo
