Dave Täht

Oh core systemd folk? @poettering @michich -I don't know who else is core to systemd - can I go back to something else in life besides this bug report now?...

I agree that tsq could probably be made more effective. I showed earlier that on this test it managed well at a gigE to 16 greedy flows. That seemed "good...

Latency "regression" my ass! a factor of 15-25X improvement, no loss in throughput. You can't put in more data than you can get out in a reasonable time - Oh,...

"This is only true if the application using TCP is a bulk transfer application. Many important applications (e.g. web traffic, RPC traffic) care about latency, and are harmed by the...

Not enough people have read this: https://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/ - it's not directly relevant to the discussion at hand, but it helps to deeply grok the impact of rtt on web traffic...

I kind of gave up on wondershaper and worked on the sqm-scripts. Currently twiddling with sch_cake.

Jaka Jančar writes: > Just removing all occurrences of "protocol ip" seems to work for me. Can't help but continue to encourage y'all to try cake, fq_codel, and the sqm-scripts...

Good point. Most of our work predates systemd. I bug noted it. how about tc qdisc add dev whatever root cake bandwidth XXMbit

relevant cap: http://snapon.lab.bufferbloat.net/~d/comcast.dhcpv6/dhcp.cap

root@ranger:/tmp# ip -6 addr show eth2 4: eth2: mtu 1500 qlen 1000 inet6 2601:646:8301:c500:225:90ff:fef4:a5c4/64 scope global dynamic valid_lft 344680sec preferred_lft 344680sec inet6 2601:646:8301:c500::1/128 scope global dynamic valid_lft 57sec preferred_lft 27sec...