Stats is only useful for measuring response time on the server. It has nothing to do with the client's perception of latency. And, that end, it is only useful to rule out the network as a problem.
The stats man page is pretty good for learning what stats is good for, and stats explain as well. A good end to end latency measure is probably only possible with application side tools, which is well beyond my knowledge. :)
-Blake
On 9/28/06, Borzenkov, Andrey Andrey.Borzenkov@fujitsu-siemens.com wrote:
The problem with stats is that counters are not documented anywhere. So while you can guess what they mean, you never know for sure.
In this particular case I am curious - how can NetApp measure client-side latency? As trivial example, consider some congestion problems on traffic from NetApp to client - NetApp will never know about it.
Which raises the question, what this counter actually means.
Regards
Andrey Borzenkov Senior system engineer IT Product Services Fujitsu Siemens Computers Russian Federation
Telephone: +7(495)737-2723 Email: mailto:Andrey.Borzenkov@fujitsu-siemens.com Internet: http://www.fujitsu-siemens.com
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Blake Golliher Sent: Thursday, September 28, 2006 9:59 PM To: Willeke, Jochen Cc: NetApp Toasters List Subject: Re: Response time measurement
That's a good way to go. I usually use the vendor provided tools, like the filer's stats command works quite well.
stats show -i 1 -r -n 30 nfsv3:nfs:nfsv3_blockop_latency
That works fairly well. If you have doubts in trusting NetApp's tools, you could correlate with the tcpdump.
-Blake
On 9/28/06, Willeke, Jochen Jochen.Willeke@wincor-nixdorf.com wrote:
Hi,
its me again thinking about measurement of response time. I have a new
idea
and just wanted to hear from you what you think about it. I am running a dd with a bs of 8k/4k against a fileserver for a couple
of
minutes and during different daytimes.
While the dd is running i do capture the networkstream and create a statistic for NFSv3-ops
tetherreal -i eth0 -z rpc,100003,3
This gives me an overview of the RTT's during this run of dd. What do you think about this method? I can use sio as well for
generating
random IO but the method will remain the same.
Best Regards and thanks in advance for any opinions on that
Jochen
From: Miller, James [mailto:James.Miller@netapp.com] Sent: Friday, September 22, 2006 7:27 PM To: Willeke, Jochen Subject: Re: Response time measurement
Isn't it 8.72ms or .00872secs ... Jim Miller sent from blackberry
-----Original Message----- From: Willeke, Jochen Jochen.Willeke@wincor-nixdorf.com To: NetApp Toasters List toasters@mathworks.com Sent: Fri Sep 22 08:13:05 2006 Subject: Response time measurement
Hi folks,
i am still thinking about some figures which help me considering different fileservers. After doing some research i think one point is the response time given by the system.
I did a lot of testing with sio and but the results i got are some
kind
of strange.
A test with SIO e.g. brings following result:
./sio_ntap_linux 100 0 8k 100m 10 1 /mnt/test15 Version: 3.00
SIO_NTAP: Inputs Read %: 100 Random %: 0 Block Size: 8192 File Size: 104857600 Secs: 10 Threads: 1 File(s): /mnt/test15 Outputs IOPS: 114578 KB/s: 916626 IOs: 1145782 Terminating threads ...Killed
First there are the KB/S. Much to fast even for a 1Gbit network. And
the
second is the response time. I calculated the following:
1s / 114578 (IOPS) = 0,00872 ms (response time)
This cannot be true at all :-) Does SIO read the same block all the time (due to 0%random read), or
do
i have any kind of mistake in my test?!?
Perhaps someone can help.
Best Regards and a nice weekend
Jochen