Henning Brauer wrote:Yes, the congestion counter is what I meant. It's increasing at around 7/s when the traffic we send it now is at peak time, which is about 40% of our total traffic that we will be sending to that box. The net.inet.ip.ifq.drops counter is increasing at a length of 100/s right now, but I'm not at that peak time either. Having those counters at that level seemed pretty high to me, but is it the case? Or out of 35-60K packets per seconds it's a number that I should not worry about? As for the ipintrq length, I've tried different values between 1000-3000 and values between those didn't seem to affect the rate of the PF congestion counter. Thanks
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| David Miller | Re: 2.6.24-rc6-mm1: some section mismatches on sparc64 |
| S.Çağlar | Rescheduling interrupts |
git: | |
| Ken Pratt | pack operation is thrashing my server |
| Aaron Bentley | Re: VCS comparison table |
| Imran M Yousuf | Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins |
| しらいしななこ | Re: [ANNOUNCE] GIT 1.5.4 |
| Marco Peereboom | Re: Real men don't attack straw men |
| Marcos Laufer | dmesg IBM x3650 OpenBSD 4.3 |
| Kevin Neff | Patching a SSH 'Weakness' |
| Steve B | Intel Atom and D945GCLF2 |
| Jeff Garzik | Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
| David Miller | Re: [BUG] New Kernel Bugs |
| Arjan van de Ven | Re: [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
