From owner-freebsd-net Tue Sep 5 7:34:43 2000 Delivered-To: freebsd-net@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 0B0CA37B422 for ; Tue, 5 Sep 2000 07:34:40 -0700 (PDT) Received: (qmail 10120 invoked from network); 5 Sep 2000 14:34:36 -0000 Received: from unknown (HELO bde.zeta.org.au) (203.2.228.102) by gidora.zeta.org.au with SMTP; 5 Sep 2000 14:34:36 -0000 Date: Wed, 6 Sep 2000 01:34:32 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Kenjiro Cho Cc: altq@csl.sony.co.jp, akorud@polynet.lviv.ua, freebsd-net@FreeBSD.ORG Subject: Re: [altq 575] Re[2]: [altq 565] Running ALTQ In-Reply-To: <20000905133613H.kjc@csl.sony.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 5 Sep 2000, Kenjiro Cho wrote: > Andriy Korud wrote: > > And few more questions: > > 1. What does ALTQ_NOPCC option mean? Will disabling it (using > > processor counters) improve limit resolution? > > It requires only one machine cycle to read a processor cycle couner > (timestamp counter for pentium), which is much cheaper than using > microtime(). However, it doesn't affect the kernel timer resolution. It takes more than one cycle, at least in a loop. I just retried the following: main() { __asm(" movl $100000000,%ecx .align 4,0x90 1: rdtsc decl %ecx nop jne 1b "); } and it took 30 cycles on a Celeron and 12 cycles on a P5 (32 and 14 cycles, respectively, including 2 cycles of loop overhead). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message