From owner-cvs-all@FreeBSD.ORG Sat Nov 15 17:48:30 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3135B16A4CE; Sat, 15 Nov 2003 17:48:30 -0800 (PST) Received: from server.vk2pj.dyndns.org (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 977E343FCB; Sat, 15 Nov 2003 17:48:27 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1])hAG1mGJD002453; Sun, 16 Nov 2003 12:48:16 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.12.9p1/8.12.9/Submit) id hAG1mEpM002312; Sun, 16 Nov 2003 12:48:14 +1100 (EST) (envelope-from peter) Date: Sun, 16 Nov 2003 12:48:14 +1100 From: Peter Jeremy To: Andre Oppermann Message-ID: <20031116014814.GB74756@server.vk2pj.dyndns.org> References: <200311142102.hAEL2Nen073186@repoman.freebsd.org> <20031114153145.A54064@xorpc.icir.org> <3FB593F5.1053E7E2@pipeline.ch> <20031115002921.B68056@xorpc.icir.org> <3FB60181.4256A519@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB60181.4256A519@pipeline.ch> User-Agent: Mutt/1.4.1i cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/netinet in_var.h ip_fastfwd.c ip_flow.c ip_flow.h ip_input.c ip_output.c src/sys/sys mbuf.h src/sys/conf files src/sys/net if_arcsubr.c if_ef.c if_ethersubr.c if_fddisubr.c if_iso88025subr.c if_ppp.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2003 01:48:30 -0000 On Sat, Nov 15, 2003 at 11:35:45AM +0100, Andre Oppermann wrote: > To put this more into perspective wrt counter wrapping, on >my interfaces I have a byte counter wrap every 40 minutes or so. >So the true ratio is probably even far less than one percent and >more in the region of one per mille. The wrapping looks really ugly >on MRTG and RRtool graphs. Interface counters should be 64bit or >they become useless with todays traffic levels... A perennial favourite. Atomically incremented 64-bit counters are _very_ expensive on i386 and the concensus is that the cost is unjustified in the general case. Feel free to supply patches to optionally (at build-time) allow selection of 32-bit or 64-bit counters. A work-around would be to simulate the top 32-bits by counting rollovers in the bottom 32 bits (though this requires co-operation by all consumers that want to see 64-bit values as well as a background process). I notice that even DEC/Compaq/HP Tru64 uses 32-bit counters for network stats. >> i am pretty sure that in any non-trivial case you will end up having >> both the slow path and the fast path conflicting for the instruction >> cache. Merging them might help -- i have seen many cases where >> inlining code as opposed to explicit function calls makes things >> slower for this precise reason. > >I will try to measure that with more precision. You did have >code which was able to record and timestamp events several >thousand times per second. Do still have that code somewhere? I've done similar things a couple of times using circular buffers along the following lines: #define RING_SIZE (1 << some_suitable_value) int next_entry; struct entry { some_time_t now; foo_t event; } ring[RING_SIZE]; void __inline insert_event(foo_t event) { int ix; /* following two lines need to be atomic to make this re-entrant */ ix = next_entry; next_entry = (ix + 1) & (RING_SIZE - 1); ring[ix].now = read_time(); ring[ix].event = event; } In userland, mmap(2) next_entry and ring to unload the events. Pick RING_SIZE and the time types to suit requirements. The TSC has the lowest overhead but worst jitter. Peter