Re: [Cake] Cake latency update

> On Feb 12, 2017, at 6:15 PM, Pete Heist wrote: > >> On Feb 12, 2017, at 5:41 PM, Jonathan Morton wrote: >> >>> On 12 Feb, 2017, at 16:12, Pete Heist wrote: >>> >>> 2) Using a 1.25 GHz Mac Mini PPC G4 I have laying around. I

Re: [Cake] Cake latency update

> On Feb 12, 2017, at 5:41 PM, Jonathan Morton wrote: > >> On 12 Feb, 2017, at 16:12, Pete Heist wrote: >> >> 2) Using a 1.25 GHz Mac Mini PPC G4 I have laying around. I successfully ran >> fq_codel for ADSL on that box in the past, but at 5 / 0.5

Re: [Cake] Cake latency update

Or, I can do: ethtool -K eth0 tx off rx off and disable the checksums entirely. That stops the messages, but unfortunately it doesn’t appear to be the end of the throughput shifts. But this experience has made me want to look at all of this on other hardware, so that’s next. > On Feb 12,

Re: [Cake] Cake latency update

> On Feb 12, 2017, at 2:08 PM, Dave Taht wrote: > > Disable offloads on the sky hardware and see what happens? > > ethtool -K gro off tso off gso off your_device I’d already had them disabled for testing in /etc/network/interfaces: post-up ethtool -K eth0 tso off gso off

Re: [Cake] Cake latency update

Disable offloads on the sky hardware and see what happens? ethtool -K gro off tso off gso off your_device How old is the OS on that hardware - offloads have always been tricksy. as to why you might be seeing it more with cake, with this stuff on, you are not necessarily checking every packet

Re: [Cake] Cake latency update

> On Feb 10, 2017, at 12:35 PM, Sebastian Moeller wrote: > > Hi Pete, > >> On Feb 10, 2017, at 12:08, Pete Heist wrote: >> >> Not a problem. I’ll run a spread of Cake and fq_codel over Ethernet at >> various bandwidths. It will be through their Apple

Re: [Cake] Cake latency update

Hi Pete, > On Feb 10, 2017, at 12:08, Pete Heist wrote: > > >> On Feb 10, 2017, at 11:31 AM, Jonathan Morton wrote: >> >> >>> On 10 Feb, 2017, at 12:05, Pete Heist wrote: >>> >>> It means that both the ingress and egress

Re: [Cake] Cake latency update

> On Feb 10, 2017, at 11:31 AM, Jonathan Morton wrote: > > >> On 10 Feb, 2017, at 12:05, Pete Heist 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

Re: [Cake] Cake latency update

> On 10 Feb, 2017, at 12:05, Pete Heist 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.

Re: [Cake] Cake latency update

> On 10 Feb, 2017, at 11:21, Pete Heist wrote: > > Here are the results at various bitrates (all half-duplex rate limiting on > this CPU). Hold on a minute. What does “half-duplex rate limiting” mean exactly? - Jonathan Morton

Re: [Cake] Cake latency update

> On Feb 10, 2017, at 9:49 AM, Jonathan Morton wrote: > > >> On 10 Feb, 2017, at 10:04, Pete Heist wrote: >> >> I look forward to the throughput shifts being solved, where I see results >> like this: >> >>

Re: [Cake] Cake latency update

> On 9 Feb, 2017, at 18:36, Pete Heist wrote: > > I’m seeing good latency results for Cake at lower MCS levels (graphs below), > in case that wasn’t already known. Yes - despite its complexity, Cake has always performed well on latency in comparison to other qdiscs. I