Philst's profile - activity

A clue that the client isn’t receiving the server’s Resets is the doubling of the time between successive client FIN pac

I agree, I'd love to see the PCAPs for these transfers so that we could see exactly what is going on. I would like to s

[Edit] Note: This answer applies to the newer "dest" and "src" PCAPs. The behaviour there is very, very different than

After a quick look at your "dest" and "src" PCAPs, I can see that the slow throughput is due to the sender going into co

To further Sake's answer: Are the packets in each capture different sizes? The 120K packets may be larger than 1460 (d

Edit 2: It's interesting how "sleeping on it" can make things clearer in one's mind. I now do think that there is a bug

Edit 2: It's interesting how "sleeping on it" can make things clearer in one's mind. I now do think that there is a bug

I don't think there's a bug with SACK behaviour. It looks like a group of 12 packets got lost after the sniffer saw the

I don't think there's a bug with SACK behaviour. It looks like a group of 12 packets got lost after the sniffer saw the

Sounds like a homework exercise.

So my guess is that only full-sized packets were dropped by the VPN endpoints - and that's why you had an apparently int

True, but a capture will help you eliminate "network" causes. It can also tell you that performance issues are inside a

That's a good question, given that you are directly connected. A capture would prove the TCP "congestion" hypothesis a

This is probably due to packet loss in your "slow" direction - but no loss in your "fast" direction. The TCP "Congestio

This is probably due to packet loss in your "slow" direction - but no loss in your "fast" direction. The TCP "Congestio

Your original "AIX-to-Cloud" capture file is made more difficult to analyse due to the fact that there are a lot of pack

Your original "AIX-to-Cloud" capture file is made more difficult to analyse due to the fact that there are a lot of pack

I just added a couple of paragraphs referring to those server "Dup-ACKs".

I see the throughput in both these captures to be very similar. "fast" achieves around 1.6 Mbps, with bytes-in-flight (

I see the throughput in both these captures to be very similar. "fast" achieves around 1.6 Mbps, with bytes-in-flight (

I see the throughput in both these captures to be very similar. "fast" achieves around 1.6 Mbps, with bytes-in-flight (

That's a good point @SYN-bit. Yes, that could cause a performance hit.

The receiving device will put the packets back into the correct order before extracting the data and passing it up t the

This is a very interesting case study. The underlying problem is that your servers begin to "misbehave" once throughput

This is a very interesting case study. The underlying problem is that your servers begin to "misbehave" once throughput

Your throughput limitation isn’t related to Receive Window sizes (or network bandwidth limits). It is entirely limited

Your throughput limitation isn’t related to Receive Window sizes (or network bandwidth limits). It is entirely limited

There's a very consistent regularity to the way the packets flow from the client to the server. A particular pattern is

I created four Tweets containing charts (not created with Wireshark though). They might help to clarify the TCP and pac

You are sending packets into your router at local LAN speed but the router can only send them to the Internet at 1 Mbps.

You are sending packets into your router at local LAN speed but the router can only send them to the Internet at 1 Mbps.

You are sending packets into your router at local LAN speed but the router can only send them to the Internet at 1 Mbps.

There's a very consistent regularity to the way the packets flow from the client to the server. A particular pattern is

There's a very consistent regularity to the way the packets flow from the client to the server. A particular pattern is

The 3-way handshake in the sender capture tells us that the AIX sender doesn't support SACK. It's possible that SACKs m

The 3-way handshake in the sender capture tells us that the AIX sender doesn't support SACK. However, SACKs may not hel

This is great example of a downstream bottleneck (1 Mbps) with a limited buffer queue (roughly 100 KB). As the packets

This is great example of a downstream bottleneck (1 Mbps) with a limited buffer queue (roughly 100 KB). As the packets

You may be right @Christian_R, but the more I look at these trace files, the more I'm convinced that it is an applicatio