[Cake] Cake latency update
moeller0 at gmx.de
Fri Feb 10 06:35:18 EST 2017
> On Feb 10, 2017, at 12:08, Pete Heist <peteheist at gmail.com> wrote:
>> On Feb 10, 2017, at 11:31 AM, Jonathan Morton <chromatix99 at gmail.com> wrote:
>>> On 10 Feb, 2017, at 12:05, Pete Heist <peteheist at gmail.com> wrote:
>>> It means that both the ingress and egress have been redirected over the same IFB device and QoS'd together.
>> Okay, I guessed as much but wanted to be sure.
>> I can’t think of any theoretical reason for these results. Cake’s flow isolation should be robust enough to cope transparently with bidirectional traffic in half-duplex mode. As you say, a C2D should easily be able to keep up, and at these modest rates I can even discount PCI bandwidth as a concern. So I might need to try to reproduce it here.
>> Does the problem go away if you use a wired link with the same setup otherwise? Or is that inconvenient to try? I have some ath9k equipped machines, but they would need to be set up.
> Not a problem. I’ll run a spread of Cake and fq_codel over Ethernet at various bandwidths. It will be through their Apple USB Ethernet adapters (used now for management), which are also connected through a switch, but I think that setup should be fine for this purpose. Should be done in a hour or so and we’ll see…
I believe the Apple USB dongles are fastEthernet only, at least the USB2 types I have available here, which for your tested bandwidth would work, but it will not allow you test at what shaper rate things go pear shaped… Also it wifi creates a bit more CPU load than wired ethernet, it _might_ make sense to concurrently excercise the WIFI cards just to re-create the SIRQ load (but probably not as the first experiment ;) ).
> Cake mailing list
> Cake at lists.bufferbloat.net
More information about the Cake