[Kevin <kem2@xxxxxxx>]

I have to agree on #5, the other ideas were steps to make sure nothing got missed or overlooked.  Also they give you a baseline for future testing.

Please let me know if the Netware is causing it.  Memory leak maybe?

Kevin

On Monday, September 8, 2003, at 05:30 PM, Robinson, Eric R. wrote:

> Number 1: Did that already. The “good” conversation shows little or no retransmission activity.
> Number 2: Haven’t done that. There are three “bad” machines, and rebooting fixes it for a while, so it doesn’t sound like cables to m
> Number 3: Did that already too (Windows 2K performance monitor). No appreciable difference in CPU/RAM utilization.
> Number 4: Fair enough, I can try that. However, these machines are part of a managed AV system and are up-to-date.
> Number 5: Somebody in another list said they had seen this before and the problem ended up being the NetWare client version. That’s currently where I’d bet my chips.
> --Eric
>
> -----Original Message-----
> From: Kevin [mailto:kem2@xxxxxxx]
> Sent: Saturday, September 06, 2003 11:33 AM
> To: Robinson, Eric R.
> Cc: ethereal-users@xxxxxxxxxxxx
> Subject: Re: [Ethereal-users] Application Keeps Acking Same Packet,then Su ddenly Catches Up
>
>  
>
> In my experience, this type of behavior is usually one of 2 things 1) Broken stack / app or 2) resource starvation of some type on the client.
>
>  
>
> Nagel has nothing to do with the acks of outstanding data. It controls the flow of outgoing data.
>
>  
>
> Did you see the segment that is not being acked on Ethereal on the client switch? I assume you are using port mirror / SPAN to collect the packets.
>
>  
>
> Your original post said more that one client exhibited this problem, but others on the same switch were fine. Is it always limited to the same clients?
>
> Some things I would do (Not in order):
>
> 1) Capture the conversation on the client switch of a good and bad client at the same time. This will give you a comparison.
>
> 2) Just because it is easy and cheap, switch the cables on the back of a good and bad client and see if there is any difference.
>
> 3) Use a simple resource logger on a good and bad client. Compare the results of CPU, I/O and Memory when the problem occurs
>
> 4) Scan for Viruses and ADWare and look for updates on the bad clients.
>
> 5) Find out what if anything is different on the bad clients. This includes software and hardware.
>
>  
>
> I am sure others can add to this list.
>
>  
>
> Kevin
>
>  
>
> On Friday, September 5, 2003, at 04:53 PM, Robinson, Eric R. wrote:
>
>  
>
> Hey Marco, thanks for the detailed reply. I learned something from your comments, but I still do not think we have zeroed in on the problem. When the client sends 9 or 10 ACKs in a row, it does it back-to-back with *far* less than 200ms delay between them. The ACKs are only 0.000002 seconds apart. It looks like a sudden rapid burst of identical ACKs. No packets are received from the server during this burst. Do you still think this looks like a network problem, or it is maybe a software/socket/stack problem?
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
> -----Original Message-----
>
> From:Marco Rommelse [mailto:m.rommelse@xxxxxxxxx]
>
> Sent:Friday, September 05, 2003 2:08 AM
>
> To:Robinson, Eric R.; ethereal-users@xxxxxxxxxxxx
>
> Subject:Re: [Ethereal-users] Application Keeps Acking Same Packet,then Suddenly Catches Up
>
>  
>
>  
>
>  
>
> Eric,
>
>  
>
>  
>
>  
>
> Ack-ing the same packet every time is tcp's only way of letting the sending party know that it has lost the tcp frame following the acked one. The reciever ack's every packet that it recieves after the lost frame with the sequence number of the frame it hasn't recieved. The server should resend that frame. When the frame has been resent, tcp acks the last sequence number + length of the last frame it has gotten in good order from the sender. The fact that you see the reciever ack-ing 9-10 times has to do with the nagle algorithm. This algorithm has an internal clock which goes off every 200 ms (standard setting). During that time it waits with ack-ing packets until it has something to send as well. If the 200 ms period has passed, and there is nothing to send, then it has to ack the packets it recieved. Your sender is probably filling up the windowsize of your reciever during that waiting period (fast sender, slow reciever), and tcp has lost a packet.
>
>  
>
> Retransmissions like this can slow things down considerably. Try replacing the lan-cables first, then the patch panels (if any), then switch switchports, then replace nic's. Test every step.
>
>  
>
>  
>
>  
>
> Marco.
>
>  
>
>  
>
>  
>
> ----- Original Message -----
>
>  
>
> Robinson, Eric R.
>
>  
>
> To:'ethereal-users@xxxxxxxxxxxx'
>
>  
>
> Sent:Friday, September 05, 2003 2:47 AM
>
>  
>
> Subject:[Ethereal-users] Application Keeps Acking Same Packet,then Suddenly Catches Up
>
>  
>
>  
>
>  
>
> Network geeks:
>
>  
>
>  
>
>  
>
> I have an application called ProLaw that runs off a NetWare server on the other side of a PIX firewall.
>
>  
>
>  
>
>  
>
> Most of my workstations perform fine. But two or three of them slow way down after a few hours of use, to the point that queries which usually take 10-15 seconds take 1.5 minutes! Meanwhile, other clients on the same switch keep working fine.
>
>  
>
>  
>
>  
>
> Traces show that during the slow periods, the client retransmits a lot of ACKs of the same data. It will transmit the same ACK maybe 9 or 10 times in a row with only about 0.000002 seconds between. Then the server finally retransmits a packet of its own.
>
>  
>
>  
>
>  
>
> When this happens, the client finally ACKs all of the previously received data at once and catches up.
>
>  
>
>  
>
>  
>
> Somebody please offer some insight on what could be happening here!
>
>  
>
>  
>
>  
>
> --Eric
>
>  
>
> <image.tiff>
>
>  
>
> _______________________________________________
>
> Ethereal-users mailing list
>
> Ethereal-users@xxxxxxxxxxxx
>
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>
>  
>
> _______________________________________________
>
> Ethereal-users mailing list
>
> Ethereal-users@xxxxxxxxxxxx
>
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-users