Hello, I have a situation with station that have video feed that writing the video directly into Netapp storage as follows. The client that write the feed write it in dv25 format (approx. 4MB/s) the issue is that every few min 2~3 we have error in write application took more than 400~800ms to write the frame causing frame lost , i have done a trace from station feed and started to analyze it i can see that Please advice Thanks asked 15 Feb '12, 02:23  tbaror |
One Answer:
First of all, deactivate the TCP protocol setting "Allow subdisectors to reassemble TCP streams" to avoid confusion when looking at time deltas. If you need to analyze time issues you should always disable it to see exactly what happened. Go to Edit -> Preferences -> Protocols -> TCP and remove the check mark. As soon as you've done that you'll see that the SMB commands will be at a different (now correct) position in the packet list info column, and you'll not have the "reassembled PDU" messages anymore. Second, I suspect that your problem may be caused by the receiver not processing data fast enough, or not offering a receive window big enough. The "Window Full" messages are a big indicator that there may be trouble with too much data streaming towards the target system, so take a look at the TCP window size values as well as the "Bytes in Flight". Either the storage system has trouble writing the incoming data to disk (which your storage admin should be able to see in the device statistics), or you have a high latency connection where the available bandwidth can't be fully exploited. answered 15 Feb '12, 03:01  Jasper ♦♦ |
Thanks Jasper for the answer ,
But i need to understand the process to be clear , since i am not so familiar how the write mechanism works.
The Client that write announce "Window Full" message since its detects the receive buffer on the storage is about to run-out of it , right?. Next the late "Write AndX Response" related to the fact the "PDU train" had some delay due to the fact of receive run out of buffer or purely system storage behave to confirm write on storage side?
Thanks
[converted to a comment]
The client doesn't announce "Window Full", it is a diagnostic message created by Wireshark. You can tell from the square brackets; everything enclosed in those is additional information coming from Wireshark when analyzing frames.
And the receive buffer we're talking about is the TCP receive buffer, it doesn't have anything to do with buffers the filer application uses. It basically tells the sender how much data may be sent before he has to stop and wait for an acknowledge packet. If you see "Window Full" that limit was reached, slowing down the Sender (though not always critically).