Re: [gentoo-user] Re: TCP Queuing problem

[Grant]

>> >> I just remembered that our AT&T modem/router does not respond to
>> >> pings.  My solution is to move PPPoE off of that device and onto my
>> >> Gentoo router so that pings pass through the AT&T device to the
>> >> Gentoo router but I haven't done that yet as I want to be on-site
>> >> for it. Could that behavior somehow be contributing to this
>> >> problem?  There does seem to be a clear correlation between user
>> >> activity at that location and the bad server behavior.
>> >
>> > If that device behaves badly in router mode by blocking just all
>> > icmp traffic instead of only icmp-echo-req, this is a good idea.
>> > You may want to bug AT&T about this problem then. It should really
>> > not block related icmp traffic.
>>
>>
>> Hi Kai, yesterday I switched my Gentoo router over to handling PPPoE
>> and pings seem to be working properly now.  The AT&T device is now
>> functioning as a modem only and passing everything through.  Today
>> I'll find out if it helps with TCP Queuing and (supposedly) related
>> http response slowdowns.
>
> You may want to set the default congestion control to fq-codel (it's in
> the kernel) if you're using DSL links. This may help your problem a
> little bit. It is most effective if you deploy traffic shaping at the
> same time. There was once something like wondershaper. Trick is to get
> the TCP queuing back inside your router (that is where you deployed
> pppoe) as otherwise packets will queue up in the modem (dsl modems use
> huge queues by default). This works by lowering the uplink bandwith to
> 80-90% of measured maximum upload (the excess bandwidth is for short
> bursts of traffic). Traffic shaping now re-orders the packets. It
> should send ACK and small packets first. This should solve your
> queuing problem.


We're talking about optimizing the DSL connection at my office but the
server is located in a data center.  I can't imagine optimizing that
office DSL connection is the way to solve this even though the http
response slowdowns do correlate to office hours.  As a note, the
slowdowns are recorded by my third-party monitoring service.

- Grant


> Between each step check dslreports.com for bufferbloat. I'm guessing it
> is currently way above 1000 ms while it should stay below 20-50 ms for
> dsl.
>
> The fq-codel congestion control fights against buffer bloat. But it can
> only effectively work if you're doing traffic shaping at least on your
> uplink (downlink may or may not be worth the effort depending on your
> use-case).
>
> Additionally, you can lower the priority of icmp-echo-reply this way so
> during icmp flooding your uplink will still work.
>
> This link may help you:
> https://www.bufferbloat.net/projects/codel/wiki/Cake/