I've been digging into packet captures to troubleshoot some issues with opening office files and renaming files from the SMB shares in my network. I've been using the SMB2 Service Response Time report to look at the stats.
The only number that is looking concerning to me is the accumulated SRT for NOTIFY:
===========================================================================
SMB2 Service Response Time Statistics - packet_capture.pcap:
Index Procedure Calls Min SRT (s) Max SRT (s) Avg SRT (s) Sum SRT (s)
---------------------------------------------------------------------------
SMB2
Notify 15 9 0.004195 11.765356 4.396085 39.564761
Create 5 836 0.000028 0.105900 0.001493 1.247830
Write 9 682 0.000030 0.108162 0.001639 1.117820
GetInfo 16 682 0.000026 0.108283 0.001113 0.759180
Read 8 693 0.000027 0.169438 0.001089 0.754692
Close 6 741 0.000026 0.121083 0.001013 0.750933
Ioctl 11 500 0.000029 0.185212 0.001105 0.552645
Tree Connect 3 5 0.000034 0.139351 0.027955 0.139776
Find 14 46 0.000027 0.015875 0.002177 0.100121
Tree Disconnect 4 10 0.000032 0.011280 0.002744 0.027444
SetInfo 17 12 0.000030 0.013050 0.001713 0.020562
Session Logoff 2 5 0.000087 0.011007 0.003529 0.017643
Session Setup 1 12 0.000098 0.007990 0.001140 0.013685
Negotiate Protocol 0 4 0.000030 0.002684 0.001063 0.004251
KeepAlive 13 1 0.001041 0.001041 0.001041 0.001041
SMB2
---------------------------------------------------------------------------
I've been trying to find supporting documentation, but have been unsuccessful so far. Would I be close to correct if I'm thinking the notify commands are asynchronous in nature and notify SRT isn't a critical metric for SMB2 performance analysis?
i.e. it's not a big deal if someone's Windows Explorer doesn't update a file time stamp or display a new file for 4 seconds after it's updated? Not like someone waiting 5-10 seconds for a small word or excel document to save to the network share...
Thanks,
Chad Worthman
