>> >> 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/
