>> >> It looks like the TCP Queuing spike itself was due to imapproxy
>> >> which I've now disabled.  I'll post more info as I gather it.
>> >
>> >
>> > imapproxy was clearly affecting the TCP Queuing graph in munin but I
>> > still ended up with a massive TCP Queuing spike today and
>> > corresponding http response time issues long after I disabled
>> > imapproxy.  Graph attached.  I'm puzzled.
>> 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.

- Grant

Reply via email to