Re: network performance, a low-level measurement

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.