Received: with ECARTIS (v1.0.0; list netdev); Thu, 20 Jan 2005 09:01:28 -0800 (PST) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j0KH1N2Y006629 for ; Thu, 20 Jan 2005 09:01:23 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j0KH1H71020330; Thu, 20 Jan 2005 18:01:17 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 4A69EEC1A1; Thu, 20 Jan 2005 18:01:17 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16879.58333.266843.335475@robur.slu.se> Date: Thu, 20 Jan 2005 18:01:17 +0100 To: jeremy.guthrie@berbee.com Cc: netdev@oss.sgi.com, Robert Olsson Subject: Re: V2.4 policy router operates faster/better than V2.6 In-Reply-To: <200501200837.40734.jeremy.guthrie@berbee.com> References: <200501191950.08567.jeremy.guthrie@berbee.com> <16879.38457.4576.598144@robur.slu.se> <200501200837.40734.jeremy.guthrie@berbee.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 560 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Jeremy M. Guthrie writes: > > > 1024 buffers on the RX of eth3. > > > > > > echo 86400 > /proc/sys/net/ipv4/route/secret_interval > > > echo 524288 > /proc/sys/net/ipv4/route/gc_thresh > > > > rhash_entries? > I left that at 2.4 million. > > > > It appears to be cruising right along now. > size IN: hit tot mc no_rt bcast madst masrc OUT: hit tot mc > GC: tot ignored goal_miss ovrf HASH: in_search out_search > 524291 74169 779 0 0 0 0 0 2 0 > 1610369017 516 0 0 0 43612 0 > 524287 74830 777 0 0 0 0 0 6 0 > 0 498 0 0 0 40504 1 > 524285 77458 949 0 0 0 0 0 4 0 > 0 619 0 0 0 42731 1 Linear search is under control and number of dst entries very high but very constant at the cost of calling GC a number of times second. But I don't understand why we do not see any GC ignored. Did you ever write to gc_min_interval in proc? Never seen rtstat's like this but it seems to do the job. --ro