Thanks for the detailed analysis. The SPAN capture was a good idea, I hadn't thought to do that for some reason. Anyway, disabling the TCP segmentation didn't seem to change anything. I haven't had a chance to look at it yet, but here is the attached SPAN capture. -----Original Message----- From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Sake Blok Sent: Tuesday, September 09, 2008 2:48 PM To: Community support list for Wireshark Subject: Re: [Wireshark-users] TCP Window Sizes On Tue, Sep 09, 2008 at 07:31:48PM +0200, Sake Blok wrote: > On Tue, Sep 09, 2008 at 12:48:59PM -0400, Aaron Allen wrote: > > From the pattern of your ack's, it looks like your server has the > nagle algorythm enabled and the Amazon server has delayed acking > enabled with a wait time of 100ms. What I think happens is the > following, but that should be checked with a trace on a spanport > as tracing on your server will be done *before* the packet is > segmented by the NIC. Hmmm... I looked at the trace again and I'm not sure anymore if it is indeed the nagle-delayed_ack problem. Could you make a trace like the one you sent, both on the server as on a laptop attached to a span-port on the switch (with your server port spanned to it)? I'd like to see the role of the TCP segmentation offloading on the delays that are visible in your trace (which seem to be occurring after every 7-8k of data and slowly increase in delaytime). Cheers, Sake _______________________________________________ Wireshark-users mailing list Wireshark-users@xxxxxxxxxxxxx https://wireshark.org/mailman/listinfo/wireshark-users
Attachment:
AmazonS3-Span.pcap
Description: AmazonS3-Span.pcap