Philst's profile - activity

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

There are a few interesting items in these captures - but in terms of the overall throughput, it does seem that the limi

There are a few interesting items in these captures - but in terms of the overall throughput, it does seem that the limi

Yes, your capture configuration is only catching half of the packets, that is, only catching packets from one side of th