Ok, it ended up being partly that, and mainly needing to increase kernel params
for max TCP window memory, otherwise there was a hard limit on what I’d
actually end up getting for the TCP window.
Rates start getting finicky with these large TCP windows, go too large and the
rates can collapse
You ran out of queue to store for that rtt.
netem limit 10 or higher for that.
On Fri, Jul 6, 2018 at 12:25 PM Pete Heist wrote:
>
>
> > On Jul 6, 2018, at 3:37 PM, Pete Heist wrote:
> >
> > I’m also satisfied for now that this shouldn’t hold us up. However, what
> > I’ll also want to try
> On Jul 6, 2018, at 3:37 PM, Pete Heist wrote:
>
> I’m also satisfied for now that this shouldn’t hold us up. However, what I’ll
> also want to try next is netem on a separate veth device from cake. I believe
> Dave’s veth testing earlier was using three namespaces / veth devices, maybe
>
This patch series adds the CAKE qdisc, and has been split up to ease
review.
I have attempted to split out each configurable feature into its own patch.
The first commit adds the base shaper and packet scheduler, while
subsequent commits add the optional features. The full userspace API and
most
When CAKE is deployed on a gateway that also performs NAT (which is a
common deployment mode), the host fairness mechanism cannot distinguish
internal hosts from each other, and so fails to work correctly.
To fix this, we add an optional NAT awareness mode, which will query the
kernel conntrack
This commit adds configurable overhead compensation support to the rate
shaper. With this feature, userspace can configure the actual bottleneck
link overhead and encapsulation mode used, which will be used by the shaper
to calculate the precise duration of each packet on the wire.
This feature
The ACK filter is an optional feature of CAKE which is designed to improve
performance on links with very asymmetrical rate limits. On such links
(which are unfortunately quite prevalent, especially for DSL and cable
subscribers), the downstream throughput can be limited by the number of
ACKs
At lower bandwidths, the transmission time of a single GSO segment can add
an unacceptable amount of latency due to HOL blocking. Furthermore, with a
software shaper, any tuning mechanism employed by the kernel to control the
maximum size of GSO segments is thrown off by the artificial limit on
This adds support for DiffServ-based priority queueing to CAKE. If the
shaper is in use, each priority tier gets its own virtual clock, which
limits that tier's rate to a fraction of the overall shaped rate, to
discourage trying to game the priority mechanism.
CAKE defaults to a simple,
This adds a global netfilter function to extract a conntrack tuple from an
skb. The function uses a new function added to nf_ct_hook, which will try
to get the tuple from skb->_nfct, and do a full lookup if that fails. This
makes it possible to use the lookup function before the skb has passed
sch_cake targets the home router use case and is intended to squeeze the
most bandwidth and latency out of even the slowest ISP links and routers,
while presenting an API simple enough that even an ISP can configure it.
Example of use on a cable ISP uplink:
tc qdisc add dev eth0 cake bandwidth
Thank you both for the great work!
I will give it a try, too.
George
On Fri, Jul 6, 2018, 9:29 AM Toke Høiland-Jørgensen wrote:
> Pete Heist writes:
>
> > I don’t know if we want to call this an issue, but...
> >
> > I’m seeing a lockup with cake (and also sfq, but not either pfifo or
> >
Pete Heist writes:
> I don’t know if we want to call this an issue, but...
>
> I’m seeing a lockup with cake (and also sfq, but not either pfifo or
> fq_codel), when run over veth devices. Two network namespaces are
> created, one for client and one for server, each with one veth device.
> Netem
Jonathan Morton writes:
>> On 6 Jul, 2018, at 4:21 pm, Toke Høiland-Jørgensen wrote:
>>
>>> I'm handling it without using any extra permanent state, just making
>>> use of what's already there. Take a look at latest commit.
>>
>> Yup, that also fixes the infinite loop issue. I'm fine with
> On 6 Jul, 2018, at 4:21 pm, Toke Høiland-Jørgensen wrote:
>
>> I'm handling it without using any extra permanent state, just making
>> use of what's already there. Take a look at latest commit.
>
> Yup, that also fixes the infinite loop issue. I'm fine with doing it
> this way; however, it
I don’t know if we want to call this an issue, but...
I’m seeing a lockup with cake (and also sfq, but not either pfifo or fq_codel),
when run over veth devices. Two network namespaces are created, one for client
and one for server, each with one veth device. Netem is added as the root qdisc
> On 6 Jul, 2018, at 3:00 pm, Toke Høiland-Jørgensen wrote:
>
> Toke Høiland-Jørgensen writes:
>
>> Since sch->q.qlen can be changed from outside cake, we can't rely on it for
>> break loops etc. So keep an internal counter that mirrors it and use that
>> for all checks.
>
> Sent this as a
Pete Heist writes:
>> On Jul 6, 2018, at 1:33 PM, Toke Høiland-Jørgensen wrote:
>>
>> AHA! Found the culprit!
>>
>> The bulk dequeue mechanism in sch_generic.c will dequeue a bunch of
>> packets at once, then check if they belong on the same hardware txq. If
>> they don't, they will be put
> On Jul 6, 2018, at 1:33 PM, Toke Høiland-Jørgensen wrote:
>
> AHA! Found the culprit!
>
> The bulk dequeue mechanism in sch_generic.c will dequeue a bunch of
> packets at once, then check if they belong on the same hardware txq. If
> they don't, they will be put back on a separate queue in
> On 6 Jul, 2018, at 2:33 pm, Toke Høiland-Jørgensen wrote:
>
> Now, to figure out what to do about it...
Okay, if qlen can be manipulated outside Cake, that breaks an assumption I
made. Let me see what I can do about changing the decisions involving it.
- Jonathan Morton
George Amanakis writes:
> I guess the aborts I reported in loop 'k' are normal, just denoting that
> a flow's deficit is <=0.
> If I increase the counter to >10k, I don't see any warnings anymore.
Yeah, some looping is fine, it's the infinite loops we want to avoid ;)
-Toke
21 matches
Mail list logo
