Re: NAPI interrupt data

[Jeff Garzik <jgarzik@pobox.com>]

jamal wrote:
> 
> On Sat, 15 Feb 2003, Jeff Garzik wrote:
> 
> 
>>bash-2.05b$ ./x.pl data.crumb
>>135 samples, 21578 avg
>>bash-2.05b$ ./x.pl data.hum
>>130 samples, 11213 avg
>>
> 
> 
> Probably the first 5-10 samples as well as the last 5-10 amples to get
> more accuracy.
> 
> This data looks fine, no?

Over 4000 interrupts per second was not something I was hoping for, to 
be honest.  ttcp did not even report 50% CPU utilization, so I reach the 
conclusion that both machines can handle well in excess of 4,000 
interrupts per second...  but overall I do not like the unbounded nature 
of the interrupt rate.  This data makes me lean towards a software[NAPI] 
+ hardware mitigation solution, as opposed to totally depending on 
software interrupt mitigation.


 > definetly the scsi device is skewing things
> (you are writting data to disk for example).

Yes, though only once 5 seconds when ext3 flushes.  With nothing else 
going on but "ttcp" and "cat /proc/interrupts >> data ; sleep 1" there 
should be very little disk I/O.  I agree it is skewing by an unknown 
factor, however.


> - The 500Kpps from ttcp doesnt sound right; tcp will slow you down.
> perhaps use ttcp to send udp packets to get a more interesting view.


No, I ran 500,000 buffer I/Os total from ttcp ("-n 500000").  That 
doesn't really say anything about packets per second.  The only thing I 
measured was interrupts per second.  It was my mistake to type "packets" 
in the first email :/

	Jeff