Hi Ari, You need to isolate the problem more, from you description, the problem could come from anywhere. I would look at the number if system interrupts, qdisc and class statistics and nic statistics provided by ethtool -S in order to isolate the problem. You could also mention ram utilisation and the kernel version running on the system. Remy On 12 February 2013 00:54, Ari Heitner <ari@xxxxxxx> wrote: > We are having a strange intermittent problem on a natting firewall that's > been loyally serving us for years, and the current theory is that our > recent major connection upgrade (to 16/7 mbit, from about 7/1) plus the > switch to voip phones, is periodically bogging down the machine, which is a > little long in the tooth - a pIII-500. > > Symptom: seemingly randomly, up to a few times a day, the network > connection just chokes for about 30 seconds. Pings and DNS still work ok, > but http traffic and seemingly anything else TCP just stops. Wait a few > seconds, and it starts again, processing the pending requests (i.e. the web > page you were waiting for suddenly loads, without hitting refresh again) > but playing havoc with voip phone calls. The behaviour seems to correlate > with the network being busy, but generally the machine can handle > throughput saturation with no problem, and does so regularly. > > My friend suggested a stress-test: making a vpn (pptp) to his network, and > seeing if that makes the nat firewall box act up. Sure enough - make the > connection, and start copying a file (at a very low throughput like 50 > kB/s) and load the network a little bit, and it freezes. And when the vpn > connection is active, even without doing anything, stuff starts getting > weird - the machine sometimes stops accepting incoming connections on port > 22, and logmein.com sessions in progress will fail. > > But through all of this the machine shows no load, and the tc in place > (wondershaper, modified slightly to prioritize traffic to and from the > remote voip server - I can post the script and tc output if it would be > useful) show no unusual amounts of packet droppage - which makes sense, > since the issue isn't a bandwidth overload. > > How can I get stats on the "health" or load or anything of the tcp/ip > stack? Am I even barking up the right tree here? > > Any and all suggestions would be appreciated. > > > Cheers, > > Ari > > -- > Ari Heitner > Director of Technology > www.NCSY.ca - www.TorahHigh.org > w: 905.761.6279 x223 m: 647.202.1998 > -- > To unsubscribe from this list: send the line "unsubscribe lartc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
