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
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)
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.