Date: Mon, 31 Jan 2005 13:35:15 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Robert Watson <rwatson@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: network performance, a low-level measurement Message-ID: <90358.1107174915@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 31 Jan 2005 11:34:03 GMT." <Pine.NEB.3.96L.1050131112831.35704A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.NEB.3.96L.1050131112831.35704A-100000@fledge.watson.org>, 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?90358.1107174915>