Re: Interface Details >Receive but no buffer ISUUE

[Hansang Bae <for_list_hbae () nyc rr com>]

Tal Bar-Or wrote:
> Hello,
> I did capture on a server that is used to download regularly big dv 
> movie  files 4Gbytes each the transfer is usually slow and i have been 
> asked to figure out why ,the server itself HP DL360 G5 with the 
> on-board broadcom(NC326i)  network card type.
> after analysing short download capture of 250Mbytes i saw huge amount 
> of Duplicate ACK along with lost segment, fast retransmits.
> i noticed that on Interface Details the *Receive but no Buffer*  is 
> huge and increasing my question is could it be the reason for such 
> latency and lost data, what could be the cause for such huge values.

Losing packets because the capturing PC can't keep up with the traffic 
is normal.  In most cases, the capturing PC has to accommodate the 
SENDING and RECEIVING packets on the monitored hosts.

Why don't you send an edicap chopped (we really only need the headers) 
packet trace where you see the most number of issues.

In general, you have to go through the following checklist
1) Make sure you're not capturing on the INGRESS *and* EGRESS point on 
the switch.  For example, if you capture the entire VLAN, you'll capture 
the same packet as it enters and exits the switch.
2) Make sure you're not dropping on the monitoring (span'ed) switch 
port.  So as you're mirroring your server's packets to the port 
connected to the PC running Wireshark, keep an eye on the switch port 
(span destination) to see if the switch is losing packets during the 
mirroring process.
3) If you are capturing on the server itself, monitor that server's port 
to make sure traffic destined for the server is not being dropped.  (and 
of course, see if Wireshark tells you that it dropped packets as well).

Now, you have to figure out if any packet losses are real or if they are 
just an artifact of switches losing packets during the mirroring process. 

For example, if you see a gap in tcp conversation (packet out of order, 
previous packet lost alerts in wireshark), but you never ever see a 
retransmission, it's a good indication that it was only lost during the 
mirroring process.

If you see duplicate ACKs *everywhere* chances are that you're capturing 
the same packet twice.  To see if this is the case, look at the IP ID.  
Do you see the same IP ID for the two ACKs?  While this is not fool 
proof, it's a good indication that you duplicated the packet.  "editcap 
-d" was designed to remove duplicates that are near each other (+/- 4 
packets I believe).

Now, it's possible that you can look for tcp.seq==xxxx to see if a 
retransmission occurred.   However, this can get a little trick if SACK 
is in use.  In fact, this exact scenario will be covered during this 
years Sharkfest. 

Now, if the fast retransmits are real, and are triggered by triple 
duplicate ACKs, then you have a real packet loss problem. 

It might be best if you upload a sample so we can help you with reading 
the trace file.  Again, you should chop it up as we only need about 128 
bytes of the packet. 

-- 

Thanks,
Hansang


___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe