network performance, a low-level measurement
Poul-Henning Kamp
phk at phk.freebsd.dk
Mon Jan 31 04:35:17 PST 2005
In message <Pine.NEB.3.96L.1050131112831.35704A-100000 at 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 at 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.
More information about the freebsd-current
mailing list