Sidebar to Apple OS X SMB issues across VPN

[David Collier-Brown]

  I did a quickie SMB profiler that works on any capture
file tethereal can read.
  Running it on this server gave me the following breakdown:

froggy> smbprofile tappin1.prof
#total calls latency  xfertime responsetime info
 1.153     5 0.230563 0.000000 0.230563 NT Transact Request, NT
 2.491    31 0.030442 0.049925 0.080368 Read AndX Request, FID
18.386   662 0.027642 0.000131 0.027773 Tree Connect AndX Request,
14.202   828 0.009235 0.007918 0.017152 NT Create AndX Request,
11.423   770 0.010534 0.004300 0.014835 Close Request  
 0.175    53 0.000956 0.002353 0.003308 Transaction2 Request FIND_FIRST2, Pattern
 1.390   644 0.002135 0.000023 0.002158 Logoff AndX Request 
 0.000     1 0.000451 0.000014 0.000465 Transaction2 Request FIND_NEXT2, Continue
 0.054   129 0.000419 0.000000 0.000419 Transaction2 Request QUERY_PATH_INFORMATION
 0.001     3 0.000186 0.000000 0.000186 Find Close2 Request 
 0.003    21 0.000165 0.000000 0.000165 Transaction2 Request QUERY_FILE_INFORMATION 
 0.000     2 0.000146 0.000000 0.000146 Echo Request  
 0.001     5 0.000115 0.000000 0.000115 NT Cancel Request 


It's read as saying the slowest on average is NT Transact Request
(which is actually a category), each co which took .2 seconds

Conversely big time-eater is Tree Connect AndX, which only takes
.02 seconds, but was called 662 times.
froggy> smbprofile -t tappin1.prof
#total calls latency  xfertime responsetime info
18.386   662 0.027642 0.000131 0.027773 Tree Connect AndX Request,
14.202   828 0.009235 0.007918 0.017152 NT Create AndX Request,
11.423   770 0.010534 0.004300 0.014835 Close Request  
 2.491    31 0.030442 0.049925 0.080368 Read AndX Request, FID
 1.390   644 0.002135 0.000023 0.002158 Logoff AndX Request 
 1.153     5 0.230563 0.000000 0.230563 NT Transact Request, NT
 0.175    53 0.000956 0.002353 0.003308 Transaction2 Request FIND_FIRST2, Pattern
 0.054   129 0.000419 0.000000 0.000419 Transaction2 Request QUERY_PATH_INFORMATION
 0.003    21 0.000165 0.000000 0.000165 Transaction2 Request QUERY_FILE_INFORMATION 
 0.001     5 0.000115 0.000000 0.000115 NT Cancel Request 
 0.001     3 0.000186 0.000000 0.000186 Find Close2 Request 
 0.000     2 0.000146 0.000000 0.000146 Echo Request  
 0.000     1 0.000451 0.000014 0.000465 Transaction2 Request FIND_NEXT2, Continue


This was a side-effect of my timing FIND_FIRST2 in large directories,
which seems to be slower that expected on OS X: we're going
to compare it to Linux next.

If this is a useful tool for the team, I'll happily donate it.

--dave

David Collier-Brown wrote:
>  I can help with the packet analysis, if you can CC me on it.
> I've been doing a lot of transaction performance work with
> network traces lately, for a new book.
> 
> --dave
> 
> Christopher R. Hertel wrote:
> 
>> On Thu, Oct 20, 2005 at 02:53:44PM -0600, Dan Tappin wrote:
>> :
>>
>>>> # tcpdump -i <interface> -s0 -w capture.cap host 192.168.0.2
>>>
>>>
>>> This is on the Xserve right?... with <interface> being my LAN  
>>> connection en0 I believe.
>>
>>
>>
>> Actually, that'd be on the client.  You only want to see traffic between
>> the client and server.  You will probably have a switch (not a hub) so 
>> the
>> switch will filter out any traffic to other nodes.  On the server side,
>> you'd see all client traffic.
>>
>> The other way to do it (from the server side) is:
>>
>> # tcpdump -i <iface> -s0 -w capture.cap host 192.168.0.2 and host 
>> <clientIP>
>>
>> ...and yes, if en0 is the name of the ethernet interface then that's 
>> what you'd put in for <iface>.
>>
>> Chris -)-----
>>
> 

-- 
David Collier-Brown,      | Always do right. This will gratify
Sun Microsystems, Toronto | some people and astonish the rest
davecb at canada.sun.com     |                      -- Mark Twain
(416) 263-5733 (x65733)   |