Hi,
Possibly a stupid question, but has someone ran
wireshark/tcpdump/windump
on the client side to verify that it is actually the client waiting
after
a filer response, and not just network latency?
Yes i did a tracing. And you see that the client is not waiting. Here some output
No time SRC DEST Protocol Info 282 0.000145 client nafiler SMB Write AndX Request, FID: 0x026b, 36 bytes at offset 0
283 0.001178 nafiler client SMB Write AndX Response, FID: 0x026b, 36 bytes
284 0.056002 client nafiler SMB Close Request, FID: 0x026b
285 0.000391 nafiler client SMB Close Response, FID: 0x026b
This is only one examlpe. The filer seems to be the faster part within this connection, doesn't it? But what causes the client to wait so long?? I was only creating a file from my client on that share.
Rgds
Jochen
On Fri, Oct 12, 2007 at 01:57:04PM +0200, Willeke, Jochen wrote:
Hi,
Possibly a stupid question, but has someone ran
wireshark/tcpdump/windump
on the client side to verify that it is actually the client waiting
after
a filer response, and not just network latency?
Yes i did a tracing. And you see that the client is not waiting. Here some output
No time SRC DEST Protocol Info 282 0.000145 client nafiler SMB Write AndX Request, FID: 0x026b, 36 bytes at offset 0
283 0.001178 nafiler client SMB Write AndX Response, FID: 0x026b, 36 bytes
284 0.056002 client nafiler SMB Close Request, FID: 0x026b
285 0.000391 nafiler client SMB Close Response, FID: 0x026b
This is only one examlpe. The filer seems to be the faster part within this connection, doesn't it?
Assuming this trace was captured on the client, yes I'd say so, although only seeing a Write AndX and a Close, I wouldn't know if those naturally have a delay like that (or in a particular program) without seeing a bunch of calls next to eachother, ideally, the same calls. I'll take your word for it.
But what causes the client to wait so long?? I was only creating a file from my client on that share.
I guess it depends what the client is doing. We have seen Firefox rebuild a configuration cache that gets stored on our server and it writes output one line at a time closing the file inbetween and it is quite slow, the operation takes almost 20 seconds sometimes. When we upgraded our Samba servers infront of the Netapp NFS share, that time was cut down approx in half, but that did not prevent the client from doing something stupid (write line by line to the network). We did not try netapp CIFS to see what happens. We are just starting to use the netapp CIFS at all, we have been 100% NFS up until now with an existing pair of samba servers.
Hi,
first thanks a lot!!
Right now i have followed Nils advice from his mail and controlled cifs.max_mpx and due to cifs stat reporting a number of 68 i raised the option to 126.
Let's see if that's it!
Rgds and thanks all for your ideas
Jochen
-----Original Message----- From: Adam McDougall [mailto:mcdouga9@egr.msu.edu] Sent: Friday, October 12, 2007 2:34 PM To: Willeke, Jochen Cc: toasters@mathworks.com Subject: Re: weird cifs problem
On Fri, Oct 12, 2007 at 01:57:04PM +0200, Willeke, Jochen wrote:
Hi,
Possibly a stupid question, but has someone ran
wireshark/tcpdump/windump
on the client side to verify that it is actually the client waiting
after
a filer response, and not just network latency?
Yes i did a tracing. And you see that the client is not waiting. Here some output
No time SRC DEST Protocol Info 282 0.000145 client nafiler SMB Write AndX Request, FID: 0x026b, 36 bytes at offset 0
283 0.001178 nafiler client SMB Write AndX Response, FID: 0x026b, 36 bytes
284 0.056002 client nafiler SMB Close Request, FID: 0x026b
285 0.000391 nafiler client SMB Close Response, FID: 0x026b
This is only one examlpe. The filer seems to be the faster part within this connection, doesn't it?
Assuming this trace was captured on the client, yes I'd say so, although
only seeing a Write AndX and a Close, I wouldn't know if those naturally have a delay like that (or in a particular program) without seeing a bunch of calls next to eachother, ideally, the same calls. I'll take your word for it.
But what causes the client to wait so long?? I was only creating a file from my client on that share.
I guess it depends what the client is doing. We have seen Firefox rebuild a configuration cache that gets stored on our server and it writes output one line at a time closing the file inbetween and it is quite slow, the operation takes almost 20 seconds sometimes. When we upgraded our Samba servers infront of the Netapp NFS share, that time was cut down approx in half, but that did not prevent the client from doing something stupid (write line by line to the network). We did not try netapp CIFS to see what happens. We are just starting to use the netapp CIFS at all, we have been 100% NFS up until now with an existing pair of samba servers.
Could be another dumb question, but have you looked at your Active Directory server? Otherwise, how do you do authentication?
Have you mapped a CIFS share from another Windows box to your client? Do you still see this weird slowness or is it just when the NetApp is the server?
Sandeep Cariapa
--- "Willeke, Jochen" Jochen.Willeke@wincor-nixdorf.com wrote:
Hi,
Possibly a stupid question, but has someone ran
wireshark/tcpdump/windump
on the client side to verify that it is actually
the client waiting after
a filer response, and not just network latency?
Yes i did a tracing. And you see that the client is not waiting. Here some output
No time SRC DEST Protocol Info 282 0.000145 client nafiler SMB Write AndX Request, FID: 0x026b, 36 bytes at offset 0
283 0.001178 nafiler client SMB Write AndX Response, FID: 0x026b, 36 bytes
284 0.056002 client nafiler SMB Close Request, FID: 0x026b
285 0.000391 nafiler client SMB Close Response, FID: 0x026b
This is only one examlpe. The filer seems to be the faster part within this connection, doesn't it? But what causes the client to wait so long?? I was only creating a file from my client on that share.
Rgds
Jochen
Hi,
yes we do use AD. I have thought of tracing a little bit domain traffic.
The problem only occurs when netapp is the server. But as i heared from the users right now (after increasing the cifs_maxpmx) everythin seems to be better.
Rgds
Jochen
-----Original Message----- From: Sandeep Cariapa [mailto:cariapa@yahoo.com] Sent: Friday, October 12, 2007 8:24 PM To: Willeke, Jochen; Adam McDougall Cc: toasters@mathworks.com Subject: RE: weird cifs problem
Could be another dumb question, but have you looked at your Active Directory server? Otherwise, how do you do authentication?
Have you mapped a CIFS share from another Windows box to your client? Do you still see this weird slowness or is it just when the NetApp is the server?
Sandeep Cariapa
--- "Willeke, Jochen" Jochen.Willeke@wincor-nixdorf.com wrote:
Hi,
Possibly a stupid question, but has someone ran
wireshark/tcpdump/windump
on the client side to verify that it is actually
the client waiting after
a filer response, and not just network latency?
Yes i did a tracing. And you see that the client is not waiting. Here some output
No time SRC DEST Protocol Info 282 0.000145 client nafiler SMB Write AndX Request, FID: 0x026b, 36 bytes at offset 0
283 0.001178 nafiler client SMB Write AndX Response, FID: 0x026b, 36 bytes
284 0.056002 client nafiler SMB Close Request, FID: 0x026b
285 0.000391 nafiler client SMB Close Response, FID: 0x026b
This is only one examlpe. The filer seems to be the faster part within this connection, doesn't it? But what causes the client to wait so long?? I was only creating a file from my client on that share.
Rgds
Jochen
-
Adam McDougall -
Sandeep Cariapa -
Willeke, Jochen