Troubleshooting High TCP Retransmit Rate

Question

im following a tutorial of flutter about using json and serialization. Im trying to execute a command in the terminal in a flutter proyect in vscode,

this is the class

import 'package:json_annotation/json_annotation.dart';

part 'mensaje.g.dart';

@JsonSerializable()
class Mensaje{
  final String subject;
  final String body;

  Mensaje(this.subject,this.body);

  Mensaje.fromJson(Map<String, dynamic> json):
    subject=json['subject'],
    body=json['body'];

}

I first add the dependecies in pubspec.yaml:

dev_dependencies:

build_runner: json_serializable:

then i try to execute in the terminal in vscode this line:

flutter packages pub run build_runner build

and the error: (flutter its not recognize as a cmdlet name or function... )

flutter : El término 'flutter' no se reconoce como nombre de un cmdlet, función, 
archivo de script o programa ejecutable. Compruebe si escribió correctamente el 
nombre o, si incluyó una ruta de acceso, compruebe que dicha ruta es correcta e 
inténtelo de nuevo.
En línea: 1 Carácter: 1
+ flutter packages pub run build_runner build
+ ~~~~~~~
    + CategoryInfo          : ObjectNotFound: (flutter:String) [], CommandNotFoundEx  
   ception
    + FullyQualifiedErrorId : CommandNotFoundException

Solution 1

One good way to detect loss is by using a UDP stream of packets (there are various tools that do this, mainly for QoS testing). You can vary size, frequency, delay. It should show you if you have actual loss.

Solution 2

To test this, I ran twelve hours of pings. At the end, the program reported less than 1% packet loss.

Ping uses ICMP packets - that's internet control message protocol. ICMP is intended to ensure traffic flows (i.e. telling other machines how to route traffic) so devices MUST prioritize ICMP over other packet types.

i.e. this is the worst possible way to detect congestion.

Solution 3

Check everything before your network. As in: The satellite link is flaky. Could be anything on the physical level of that side - bad calibration, whatever.

As per the Sherlock Holmes Approach that is the only thing left. Packets are lost because they are LOST.

Comments

[Erick Brown]

The ping test was performed from a Windows 7 (32-bit) machine with tcpip.sys version 6.1.7601.22525 (11/26/13). The target of the ping was Google's DNS server, 8.8.8.8. I don't know what OS it runs, but I'm guessing it's not Windows

[Greg Askew]

Forgetting the Google ping test, what is the MTU of the link to the hosts where you are experiencing retransmits? Also, can you provide the output of the command: netsh interface tcp show global

[Greg Askew]

A standard MTU on a LAN is 1500. If you subtract 28 from that, you should be able to ping a remote host with ping -f -l 1472 n.n.n.n with no timeouts or DF warnings. I have to say that "hundreds of clients" sharing a 1Mbit down/512 kbps up connection I would expect to see a lot of retransmits though.

[Erick Brown]

I completely agree r/e the number of clients and the link size. But since we see the same retransmit rate when the link is running at 10% utilization, we know that there's something else going on too. I like your idea on beefing up the ping size to help it catch drops

[Greg Askew]

Actually using the largest size payload is to determine the actual MTU, not what the client os thinks the MTU is. If you get a timeout or a DF warning, drop the payload size until it works. That is the actual MTU.

[rickhg12hs]

So, how did the large payload ping tests work?

[Erick Brown]

If the satellite link was flaky, wouldn't 12 hours of pings shown more than 1% packet loss? Or am I thinking about that the wrong way?

[TomTom]

Yes. Ping packets are very small for example. Ping also may be faked. I just say - if you eliminate everything that is not it, then the remaining has to be it. And everything before your first ethernet cable all that is left. And that is the satellite link.

[Erick Brown]

That's a good point. Pings are small. An intermittent problem would be hundreds of times more likely to manifest in packets at the full MTU than they would be in a ping

[LMSingh]

+1 for helpful info that "it's the worst way to detect congestion". The answer would be even more helpful, if you could suggest a few good ways to detect congestion in this situation.