Infinite ping - Githubissues

jsdelivr / globalping-cli

A simple CLI tool to run networking commands remotely from hundreds of globally distributed servers

Mozilla Public License 2.0

118 stars 14 forks source link

Infinite ping #86

Closed radulucut closed 6 months ago

radulucut commented 7 months ago

Adds support for the --infinite flag on the ping command.

--limit will be set to max 5 when used with --infinite
--packets default to 16 when --infinite is used

Example

```bash globalping ping cdn.jsdelivr.net from Europe --infinite > EU, SE, Stockholm, ASN:42708, GleSYS AB PING (142.250.186.46) 56(84) bytes of data. 64 bytes from fra24s04-in-f14.1e100.net (142.250.186.46): icmp_seq=1 ttl=59 time=25.2 ms 64 bytes from fra24s04-in-f14.1e100.net (142.250.186.46): icmp_seq=2 ttl=59 time=24.9 ms 64 bytes from fra24s04-in-f14.1e100.net (142.250.186.46): icmp_seq=3 ttl=59 time=25.2 ms 64 bytes from fra24s04-in-f14.1e100.net (142.250.186.46): icmp_seq=4 ttl=59 time=25.6 ms 64 bytes from fra24s04-in-f14.1e100.net (142.250.186.46): icmp_seq=5 ttl=59 time=28.2 ms 64 bytes from fra24s04-in-f14.1e100.net (142.250.186.46): icmp_seq=6 ttl=59 time=31.5 ms ^C ```

Example - multiple locations

```bash globalping ping google.com from Europe --limit 5 --infinite Location | Sent | Loss | Last | Min | Avg | Max EU, IT, Milan, ASN:16509, Amazon.com, Inc. | 8 | 0.00% | 0.68 ms | 0.66 ms | 0.69 ms | 0.74 ms EU, GB, London, ASN:20473, The Constant Company, LLC | 7 | 0.00% | 1.25 ms | 1.24 ms | 1.29 ms | 1.35 ms EU, DE, Essen, ASN:6805, Telefonica Germany GmbH & Co.OHG | 8 | 0.00% | 24.5 ms | 24.5 ms | 25.0 ms | 25.8 ms EU, NO, Oslo, ASN:63473, HostHatch, LLC | 8 | 0.00% | 7.88 ms | 7.88 ms | 7.94 ms | 8.07 ms EU, FR, Roubaix, ASN:16276, OVH SAS | 7 | 0.00% | 4.19 ms | 4.18 ms | 4.22 ms | 4.26 ms ^C ```

jimaek commented 7 months ago

Looks good, I think we could use this for the comparison feature as well. e.g. if user provides 2 endpoints then automatically use this formatting. @MartinKolarik what do you think?

MartinKolarik commented 7 months ago

@jimaek you mean top half of the screen for target A and bottom half for B?

jimaek commented 7 months ago

@jimaek you mean top half of the screen for target A and bottom half for B?

Yes,but we can support multiple targets then

MartinKolarik commented 7 months ago

Could be, but let's finish up and test the continuous part first.

jimaek commented 7 months ago

Regarding the PR itself, currently, in single probe mode, there is a delay that makes it look like it's stuck until it updates again. It should look more like normal ping, which looks and feels real-time. If there's a refresh delay then lets lower it.

The summary mode looks good on my environment.

jimaek commented 7 months ago

Please also follow the same format https://share.perfstack.net/2024/01/Termius_2024-01-18_18-02-14.png

jimaek commented 7 months ago

Weird behaviour, take a look at how the hostname changes. This should not be happening. Maybe some data is getting mixed? Normal ping seems to be correct too

# ./globalping-cli ping google.com from germany --infinite 
> EU, DE, Munich, ASN:61098, Akenes SA
PING google.com (172.217.16.174) 56(84) bytes of data.
64 bytes from fra15s11-in-f14.1e100.net (172.217.16.174): icmp_seq=1 ttl=120 time=0.55 ms
64 bytes from fra15s11-in-f14.1e100.net (172.217.16.174): icmp_seq=2 ttl=120 time=0.61 ms
64 bytes from muc11s27-in-f14.1e100.net (172.217.16.174): icmp_seq=3 ttl=120 time=0.54 ms
64 bytes from muc11s27-in-f14.1e100.net (172.217.16.174): icmp_seq=4 ttl=120 time=0.55 ms
64 bytes from fra15s11-in-f174.1e100.net (172.217.16.174): icmp_seq=5 ttl=120 time=0.59 ms
64 bytes from fra15s11-in-f174.1e100.net (172.217.16.174): icmp_seq=6 ttl=120 time=0.57 ms
64 bytes from fra15s11-in-f14.1e100.net (172.217.16.174): icmp_seq=7 ttl=120 time=0.62 ms
64 bytes from fra15s11-in-f14.1e100.net (172.217.16.174): icmp_seq=8 ttl=120 time=0.63 ms
64 bytes from muc11s27-in-f14.1e100.net (172.217.16.174): icmp_seq=9 ttl=120 time=0.59 ms
64 bytes from muc11s27-in-f14.1e100.net (172.217.16.174): icmp_seq=10 ttl=120 time=0.56 ms
64 bytes from muc11s27-in-f14.1e100.net (172.217.16.174): icmp_seq=11 ttl=120 time=0.57 ms
64 bytes from fra15s11-in-f14.1e100.net (172.217.16.174): icmp_seq=12 ttl=120 time=0.56 ms
64 bytes from fra15s11-in-f14.1e100.net (172.217.16.174): icmp_seq=13 ttl=120 time=0.57 ms
64 bytes from fra15s11-in-f174.1e100.net (172.217.16.174): icmp_seq=14 ttl=120 time=0.58 ms
64 bytes from fra15s11-in-f14.1e100.net (172.217.16.174): icmp_seq=15 ttl=120 time=0.57 ms
64 bytes from fra15s11-in-f14.1e100.net (172.217.16.174): icmp_seq=16 ttl=120 time=0.55 ms
64 bytes from fra15s11-in-f174.1e100.net (172.217.16.174): icmp_seq=17 ttl=120 time=0.54 ms
64 bytes from fra15s11-in-f14.1e100.net (172.217.16.174): icmp_seq=18 ttl=120 time=0.59 ms
64 bytes from fra15s11-in-f14.1e100.net (172.217.16.174): icmp_seq=19 ttl=120 time=0.57 ms
64 bytes from muc11s27-in-f14.1e100.net (172.217.16.174): icmp_seq=20 ttl=120 time=0.55 ms
64 bytes from fra15s11-in-f174.1e100.net (172.217.16.174): icmp_seq=21 ttl=120 time=0.57 ms
64 bytes from fra15s11-in-f174.1e100.net (172.217.16.174): icmp_seq=22 ttl=120 time=0.57 ms

radulucut commented 7 months ago

Not sure. If you increase the number of packets you can sometimes encounter it in the normal ping too. https://api.globalping.io/v1/measurements/Aaom8hWPxIJNHeb5

radulucut commented 7 months ago

Multi-location live updates do not seem to work properly on Git Bash (I've raised an issue here), it appends a new table on every refresh. Should I find an alternative or we can live with it for now?

MartinKolarik commented 7 months ago

Multi-location live updates do not seem to work properly on Git Bash (I've raised an issue https://github.com/pterm/pterm/issues/616), it appends a new table on every refresh.

I don't have this issue, it only happened when I resized the terminal while the command was running. Without resizing, it worked fine.

[ ] However, both in Git for Bash and the regular cmd.exe, the updating is quite slow and results in visible flicker. Not sure if we can do anything about it, but let's check: https://dl.dropboxusercontent.com/scl/fi/fpl36ie9qvfl09b5bpvy7/2024-01-19_16-52-02.gif?rlkey=yu31x2a7ofp135o1st9gy0gyl&dl=0 No problems when running in the same terminal app via WSL. I guess this issue was present before as well but in the regular output mode, it isn't as obvious.

MartinKolarik commented 6 months ago

@jimaek please retest as well.

MartinKolarik commented 6 months ago

Merging, let's continue in #91.