On Sun, 27 Feb 2000, Stephen Satchell wrote:
> At 09:42 PM 2/27/00 -0500, jamal wrote:
> >So maybe BSD knows how to do this; not sure how vmstat -i works: i.e how
> >accurate it is, what kind of measurement windows it is.
> >Theres no way /proc/interrupts could tell you the rate.
>
> #!/bin/sh
> T3DEVICE=eth0
> >interrupt.log
> for h in 0 1 2 3 4 5 6 7 8 9 ; do
> for r in 0 1 2 3 4 5 6 7 8 9 ; do
> for t in 0 1 2 3 4 5 6 7 8 9 ; do
> echo $h$r.$t = `cat /proc/interrupts | grep $T3DEVICE` >>interupt.log
> sleep 360
> done;
> done;
> done;
>
There you go. Wait for 6 minutes before you take your next sample. This is
what i was asking Denis in regards to the measurement window. What does
vmstat -i use as a measurement window?
6 minutes (above) is not accurate because it doesnt catch peaks really.
You try to make your window smaller and you end up stressing the system.
Especially with reading /proc and defeat the whole purpose of the test.
I have a feeling that vmstat uses a much finer window given that they were
able to capture a rate of 110Kpps.
> With a little EXCEL magic I can give you a histogram over the 100 hours
> showing rate deviations over the test.
>
> But I can do a little better, and get some additional information by using
> "proc/net/dev" to capture the RX and TX packet rate (which is what we were
> trying to measure, wasn't it?) and also see the error counters.
>
> The interrupt rate might not be the best measure, because you could get
> multiple interrupts per packet if the packet was large enough.
I have honestly never heard of such a phenomena ;-> Surely, you cant be
confusing this with interupt coalescing where you have a single interupt
for multiple packets?
> I could
> also see where you would get an interrupt when the transmit buffer was
> exhausted and you had nothing more to transmit.
>
And a thousand other events. TX completion etc;
> As a driver writer, I love to find ways to make every interrupt count, so I
> would try to do multiple operations...which means that the interrupt count
> could then underreport the packet transfer capability.
>
> Now go ahead and tell me that your statement was a troll... :)
>
It was not and you were just missing the point. Good you are not yet
writting a book on this ;->
The packet rate is the best measure. But the real Mccoy is to
see how many interupts/sec your system can withstand.
Traditionaly people map a single packet arrival to an interupt. Looking at
the interupt per sec (as in using vmstat -i) is definetly one way to
measure things. At high packet rates it becomes too burdensome on the
system. One solution is to have multiple packets giving you one
interupt. This is of course at the expense of increasing your node latency
processing.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.rutgers.edu
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:27 EST