jamal wrote:
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.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 avgProbably the first 5-10 samples as well as the last 5-10 amples to get more accuracy. This data looks fine, no?
> definetly the scsi device is skewing things
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.(you are writting data to disk for example).
- 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
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
