Interesting... net.ip.ifq.drops was indeed showing quite a bit of activity. I ratcheted up the net.ip.ifq.maxlen a bit based on the recommendations I've seen (up to 250-300), and the general performance improved quite a bit. The 'drops' stabilized pretty cleanly for a while, and video stuff seemed much cleaner, even during our inbound peak hours of over 100Mbps / 14k pps.
However, I'm seeing right now (which is REALLY weird) way more incrementing counters on 'drops' (when our inbound bandwidth/pps is around 80 Mbps / 8.5k pps) than I was seeing earlier today when we were running around 110 Mbps / 13k pps. MRTG also shows lots of 'Errors In' on the OpenBSD firewall interfaces, though nothing on the Cisco switch it's hooked to. Doing a 'netstat -idq' and checking the 'Ierrs' field show a lot of increasing input errors which correlate to the 'Errors In' field in MRTG. # netstat -idq Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Colls Drop em2 1500 <Link> 00:04:23:c2:4c:2a 4111541158 9735 3500050722 0 0 0 Very odd indeed. I don't think we're pushing THAT much traffic. It seems like we're now getting more errors with less traffic. I like using MP for the IOAPIC to reduce interrupts, but I'll try uni-processor mode just to see what happens. Other ideas? On 10/23/06, Stuart Henderson <[EMAIL PROTECTED]> wrote:
On 2006/10/23 15:08, Gunga Din wrote: > We have two OpenBSD firewalls running in CARP redundant mode, one > active, one standby. The problem we've been seeing for a while > appears to be packet loss at our firewall once we reach or surpass > around 100Mbps / 12k pps. I've seen this show up on both 3.9 stock > and the download of 4.0. It is replicable on both boxes. how's net.ip.ifq.drops? if it's showing many drops then bump net.inet.ifq.maxlen (maybe in the 100-300 range but you'll need to test to find what works best). maybe worth trying a uniprocessor kernel too. > OpenBSD 4.0 (GENERIC.MP) #933: Fri Sep 1 12:06:05 MDT 2006 "not quite 4.0" :-) (#936: Sat Sep 16)
