2021-04-08 05:39:33 +0000 | edited answer | macOS SMB uploads to Windows Server share hang for dozen of seconds 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 |
2021-04-08 05:35:20 +0000 | edited answer | macOS SMB uploads to Windows Server share hang for dozen of seconds 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 |
2021-04-06 07:11:42 +0000 | edited answer | macOS SMB uploads to Windows Server share hang for dozen of seconds 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 |
2021-04-05 06:57:18 +0000 | commented answer | macOS SMB uploads to Windows Server share hang for dozen of seconds 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 |
2020-10-01 06:35:46 +0000 | commented question | Analysing pcap Sounds like a homework exercise. |
2020-09-14 11:27:57 +0000 | commented answer | TCP/TLS Dropped packets, I don't know where to look for the issue? So my guess is that only full-sized packets were dropped by the VPN endpoints - and that's why you had an apparently int |
2020-03-17 01:39:16 +0000 | commented answer | What causes retransmissions? True, but a capture will help you eliminate "network" causes. It can also tell you that performance issues are inside a |
2020-03-11 04:02:55 +0000 | commented answer | What causes retransmissions? That's a good question, given that you are directly connected. A capture would prove the TCP "congestion" hypothesis a |
2020-03-09 03:35:42 +0000 | edited answer | What causes retransmissions? This is probably due to packet loss in your "slow" direction - but no loss in your "fast" direction. The TCP "Congestio |
2020-03-09 03:34:50 +0000 | received badge | ● Rapid Responder (source) |
2020-03-09 03:34:50 +0000 | answered a question | What causes retransmissions? This is probably due to packet loss in your "slow" direction - but no loss in your "fast" direction. The TCP "Congestio |
2020-03-05 06:46:28 +0000 | edited answer | Duplicate ACK and TCP Retransmission Your original "AIX-to-Cloud" capture file is made more difficult to analyse due to the fact that there are a lot of pack |
2020-03-05 06:28:51 +0000 | received badge | ● Rapid Responder (source) |
2020-03-05 06:28:51 +0000 | answered a question | Duplicate ACK and TCP Retransmission Your original "AIX-to-Cloud" capture file is made more difficult to analyse due to the fact that there are a lot of pack |
2019-12-20 08:03:13 +0000 | received badge | ● Commentator |
2019-12-20 08:03:13 +0000 | commented answer | comparison between two capture I just added a couple of paragraphs referring to those server "Dup-ACKs". |
2019-12-20 08:02:23 +0000 | edited answer | comparison between two capture I see the throughput in both these captures to be very similar. "fast" achieves around 1.6 Mbps, with bytes-in-flight ( |
2019-12-18 08:49:03 +0000 | edited answer | comparison between two capture I see the throughput in both these captures to be very similar. "fast" achieves around 1.6 Mbps, with bytes-in-flight ( |
2019-12-18 08:24:43 +0000 | answered a question | comparison between two capture I see the throughput in both these captures to be very similar. "fast" achieves around 1.6 Mbps, with bytes-in-flight ( |
2019-12-18 08:06:58 +0000 | received badge | ● Enthusiast |
2019-12-15 10:59:43 +0000 | commented answer | Out of order impact? That's a good point @SYN-bit. Yes, that could cause a performance hit. |
2019-12-15 07:58:43 +0000 | answered a question | Out of order impact? The receiving device will put the packets back into the correct order before extracting the data and passing it up t the |
2019-05-02 00:26:49 +0000 | commented question | Low throughput between vmWare hosts in vxlan topology - spurious retransmissions. This is a very interesting case study. The underlying problem is that your servers begin to "misbehave" once throughput |
2019-05-02 00:25:50 +0000 | commented question | Low throughput between vmWare hosts in vxlan topology - spurious retransmissions. This is a very interesting case study. The underlying problem is that your servers begin to "misbehave" once throughput |
2018-12-21 12:34:05 +0000 | received badge | ● Necromancer (source) |
2018-12-21 07:56:52 +0000 | edited answer | How to determine throughput/bandwidth from a capture (as used in TCP window scaling) Your throughput limitation isn’t related to Receive Window sizes (or network bandwidth limits). It is entirely limited |
2018-12-21 07:49:44 +0000 | answered a question | How to determine throughput/bandwidth from a capture (as used in TCP window scaling) Your throughput limitation isn’t related to Receive Window sizes (or network bandwidth limits). It is entirely limited |
2018-12-11 07:58:08 +0000 | edited answer | Excessive TCP Dup ACK and TCP Retransmissions There's a very consistent regularity to the way the packets flow from the client to the server. A particular pattern is |
2018-12-08 07:39:17 +0000 | received badge | ● Good Answer (source) |
2018-12-07 13:16:50 +0000 | received badge | ● Nice Answer (source) |
2018-12-07 10:24:30 +0000 | received badge | ● Teacher (source) |
2018-12-07 08:27:55 +0000 | commented answer | TCP Slow Start Graph I created four Tweets containing charts (not created with Wireshark though). They might help to clarify the TCP and pac |
2018-12-07 06:45:35 +0000 | commented answer | TCP Slow Start Graph You are sending packets into your router at local LAN speed but the router can only send them to the Internet at 1 Mbps. |
2018-12-07 06:44:50 +0000 | commented answer | TCP Slow Start Graph You are sending packets into your router at local LAN speed but the router can only send them to the Internet at 1 Mbps. |
2018-12-07 06:44:17 +0000 | commented answer | TCP Slow Start Graph You are sending packets into your router at local LAN speed but the router can only send them to the Internet at 1 Mbps. |
2018-12-07 05:39:11 +0000 | received badge | ● Editor (source) |
2018-12-07 05:39:11 +0000 | edited answer | Excessive TCP Dup ACK and TCP Retransmissions There's a very consistent regularity to the way the packets flow from the client to the server. A particular pattern is |
2018-12-07 05:34:35 +0000 | received badge | ● Rapid Responder (source) |
2018-12-07 05:34:35 +0000 | answered a question | Excessive TCP Dup ACK and TCP Retransmissions There's a very consistent regularity to the way the packets flow from the client to the server. A particular pattern is |
2018-12-07 04:38:14 +0000 | commented question | Excessive TCP Dup ACK and TCP Retransmissions The 3-way handshake in the sender capture tells us that the AIX sender doesn't support SACK. It's possible that SACKs m |
2018-12-07 03:11:13 +0000 | commented question | Excessive TCP Dup ACK and TCP Retransmissions The 3-way handshake in the sender capture tells us that the AIX sender doesn't support SACK. However, SACKs may not hel |
2018-12-06 08:03:25 +0000 | commented answer | TCP Slow Start Graph This is great example of a downstream bottleneck (1 Mbps) with a limited buffer queue (roughly 100 KB). As the packets |
2018-12-06 07:58:19 +0000 | commented answer | TCP Slow Start Graph This is great example of a downstream bottleneck (1 Mbps) with a limited buffer queue (roughly 100 KB). As the packets |
2018-12-06 07:27:06 +0000 | commented answer | TCP is limiting the use of bandwidth 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 |
2018-12-05 06:23:31 +0000 | received badge | ● Autobiographer |
2018-12-03 05:46:26 +0000 | commented answer | TCP is limiting the use of bandwidth There are a few interesting items in these captures - but in terms of the overall throughput, it does seem that the limi |
2018-12-03 05:32:48 +0000 | commented answer | TCP is limiting the use of bandwidth There are a few interesting items in these captures - but in terms of the overall throughput, it does seem that the limi |
2018-10-12 08:45:17 +0000 | commented question | Troubleshoot slow TCP Throughput in L2MPLS Link Yes, your capture configuration is only catching half of the packets, that is, only catching packets from one side of th |
2018-10-12 01:21:33 +0000 | received badge | ● Supporter (source) |