Acceptable SRT for SMB2 Notify?

asked 2019-07-29 13:27:52 +0000

Chad Worthman
1 ●1 ●1 ●1

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

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2019-09-25 20:51:54 +0000

Guy Harris
19890 ●3 ●659 ●207

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?

Well, that's arguably a problem, because that should really happen sooner...

...but it won't show up as a large SRT for the SMB2 CHANGE_NOTIFY request. As Eddi notes, and as you indicate by referring to the commands as "asynchronous in nature", the time between a CHANGE_NOTIFY request and the corresponding CHANGE_NOTIFY reply can be arbitrarily long. If a request is posted 2019-09-25 at 13:39, but no file in the directory is changed until 2019-10-25, the response will arrive about 30 days later.

The problem you're seeing would be a delay between the change and the CHANGE_NOTIFY reply being put on the network by the server, a delay between the CHANGE_NOTIFY reply being put on the network by the server and being received on the client's adapter, a delay between the reply being received on the adapter and being delivered to a FindFirstChangeNotification()/FindNextChangeNotification() call in Explorer, or between that indication being delivered to the call and Explorer updating the window.

A network trace won't help with the first or third of those. Network traces on both the client and the server (with reasonably synchronized clocks) may help with the second of those. A network trace would only help with the last of those if Explorer has to make further SMB calls to get file information before updating the window.

edit flag offensive delete link

add a comment

answered 2019-09-25 19:23:30 +0000

Eddi

2379 ●8 ●48 ●59

Hi Chad

Hopefully the answer is not too late.

When investigating SMB response times, SMB Notify is usually not a problem. "Notify" is the servers way to tell the client "Hey, that directory you are looking at has changed".

When you open an Explorer window you want to see changes to the directory content. The client tells the server "Hey, Notify me when something happens with this directory". 40 seconds later an other applications adds a new file to the directory. That's when the Notify messages comes in with a matching response time.

Hope that helps, happy sniffing

Eddi

edit flag offensive delete link

Comments

Hi Eddi, thanks for that information. I am a bit confused regarding "notify", because after opening a network folder containing an access database, SMB stream stops and we have a TCP delay of 22 seconds and client PC freezes. (In other TCP streams data flows meanwhile, which I removed. The delayed packet really is the next packet of SMB stream). I captured that delay and "notify". PCAP Can this be related to a delayed notify or rather not? From that information I have red this must be unrelated.

Thank you!

wshark_de ( 2019-09-27 14:52:09 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Acceptable SRT for SMB2 Notify?

2 Answers

Comments

Your Answer

Question Tools

Stats

Related questions

Acceptable SRT for SMB2 Notify? edit

2 Answers

Comments

Your Answer

Question Tools

Stats

Related questions

Acceptable SRT for SMB2 Notify?