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
|