From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 12:35:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 929A216A4CE; Mon, 31 Jan 2005 12:35:17 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id B35BE43D31; Mon, 31 Jan 2005 12:35:16 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0VCZFM9090359; Mon, 31 Jan 2005 13:35:15 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 31 Jan 2005 11:34:03 GMT." Date: Mon, 31 Jan 2005 13:35:15 +0100 Message-ID: <90358.1107174915@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: current@FreeBSD.org Subject: Re: network performance, a low-level measurement X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 12:35:17 -0000 In message , Robert Watson writes: >What about INVARIANTS? That causes an extra mutex grab and release on >each allocation and free, so INVARIANTS should be disabled in any >performance-sensitive or timing-sensitive measurements. new test starting in a moment. >> o unshared interrupt line >> o if_sis driver modified to FAST intr which just schedules >> the existing sis_intr on taskqueue_fast >> o single-user mode >> o A back-to-back cable to another machine. >> o A single default sized ping packet >> >> >> Time [uSec] Where >> ----------------------------------------------------------------------- >> 000.000 HW-intr start >> 011.600 HW-intr stop > >So this is the time window from the edge of the interrupt being raised, to >it being lowered as a result of ACK'ing the hardware, or what exactly? yes, this is the measured width of the signal on the physical interrupt wire running from the chip. >it being lowered as a result of ACK'ing the hardware, or what exactly? Do >you have any timing related to when the low level interrupt code enters, >the fast handler starts running, when it stops running, and when the low >level code returns (followed shortly by preemption)? Hmm, I can do that I think. >> 067.200 Enter sis_intr_task() >> 074.000 Enter sis_rxeof() >> 134.800 Enter ifp->if_input() >> 552.800 Enter sis_startl() > >Is net.isr.enable=1 or net.isr.enable=0? Whatever the default is. >Why are we entering sis_start() >here if net.isr.enable=0 and the system is otherwise idle? sis_start is called to return the ICMP ECHO reply packet obviously :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.