Hello, I have current situation a client (win2k3) 1Gigbit net that using to edit video with flowing format HD 100mbit + 4 wave Chanel audio , the media is located on storage (exanet ,redhat based). The issue is that while the client reading the video and when he needs to slide/scroll back the video the video is playing but the sound is getting behind the video lip-sync. I did a trace of 60 sec in around 22 sec to 27 slide/scroll back occur few sec after it we saw the sound getting behind the video lip-sync , in our video definition usually after 40ms DELAY we start to see lost frame or lip-sync issues . i did some analyze on the trace i can see that the storage having some delay read request issues few seconds after scrolling back the video more than half a minute and even more further. whats bothers me in the trace that when analyzing tcp.analysis.ack_rtt as well i can see that there is some periods of trace more than 50ms delays from both client and server , can i get into conclusion that the client suffer from some network congestion or also the storage?. any idea and tips would be appreciated since its one of my first smb analyzing. Please advice Thanks asked 09 Jun '11, 06:05  tbaror |
3 Answers:
You can go and start troubleshooting SMB in several way's but there's a lot of dark corners in that protocol! Here's what i do first: 1.check if SMB version 1 is used (in SMB 2.1, loads of things have changed): You can find these values in the SMB negotiation part of an SMB conversation, right after the TCP 3-way handshake, use “smb.cmd == 0x72” which means filter on all “SMB Command: Negotiate Protocol (0x72)” to see what dialects the client is capable of. The last dialect listed, NT LM 0.12, is SMB 1.0. And after see what client and server have agreed upon, find the response to this request (eg “Negotiate Protocol Response (0x72)”) In short you can tell by only looking if the agreed upon value is SMB 1.0 by filtering on “smb.dialect.index == 5”
Here you can find wich command gives the largest delay's , sort the rows, then right click and "prepare a filter" , use the filter (and save it for a rainy day) , f.i. "smb.cmd==50" Before you are all smb commands wich took the longest to complete, now mark 'm all by ctrl+shift+M, then clear..
Maybe you've already used the time sort column to find the same answer? View>TimeDisplayFormat>SecondsSincePreviousDisplayedPacket, then doubleclick on Time Column and go back up and see the packets that took the longest (be aware that this depends on your filter (eg filter on smb and this TimeFormat means that large time difference you see is the time that passed since the last packet that matched your smb filter was seen!). If i find something interesting i always go back to the tcp stream concerning to see what follows what exactly. This is just a start, after you find what packets cause the delays you might need to sort out the application, sort out reg files, and so on... PS loads of this i've actually picked up from Joke Snelders, go and read her blogs on wireshark http://www.lovemytool.com/blog/joke-snelders/ great stuff! answered 14 Jun '11, 00:17  Marc |
Thanks Cheers answered 14 Jun '11, 01:23 tbaror |
Now seeing your graphs, go and see why it takes so long between the read request from client to the acknowledgement from the server eg mark the read request, follow tcp stream, clear filtering, then start from marked packet untill you see the ack from storage. Can't be that many packets? If the ack after the req is fast (eg low latency, fast response, which would mean no hardware issues) if the data after the ack is slow to come, probably means that the application proces is slow. If this is the case go and "process explore" the storage. regards , Marc answered 14 Jun '11, 10:22 Marc |
