End to End vs WAFL drilldown

[mzp45]

Hi @madden,

This is in reference to the following post. I posted my query there but because its already resolved it looks like it may have not got your attention. 

http://community.netapp.com/t5/OnCommand-Storage-Management-Software-Discussions/Harvest-Dashboard-Netapp-Detail-Volume-Difference-between-WAFL-vs-End...

When you say end-to-end is from the client, does it mean latency from client to the filer or latency from client to the filer and back (RTT)? Also do you know how cDOT calculates that number? In my case I have a client accessing a volume over NFSv3

Thanks 

[madden · Accepted solution]

Hi @mzp45

End-to-end latency includes network, host, and external server (vscan/fpolicy) latency.  Network and host latency is only possible for SAN protocols when the underlying SCSI protocol uses mulitple cmds as part of an operation.  If the operation includes multiple cmd exchanges we accumulate any time after we put our cmd on the network and until we receive the next from the host, into the 'network' category.  So if there are drops on the network [TCP is recovering], or the host is CPU bound [lots of queue time on the host] we will see it.

For NAS the only time you should see network as a non-zero value is if you are using some external service like vscan or fpolicy, or maybe LDAP for credentials, and ONTAP is waiting on those to respond.

Cheers,
Chris Madden

Storage Architect, NetApp EMEA (and author of Harvest)

Blog: It all begins with data

If this post resolved your issue, please help others by selecting ACCEPT AS SOLUTION or adding a KUDO or both!

[mzp45]

Hi @madden,

Thanks for the clarification of the graphs. 

We do have an auditing tool that uses fpolicy as well as LDAP configuration so its quite likley that might be why we are seeing end-to-end but no wafl latency. I'm going to turn off auditing and see if that gets rid of the latency. 

Thanks