Infinite ping
jimaek opened this issue · 12 comments
With the probe reusing functionality on the API level we can now emulate a continuous non-stop ping. Maybe a new ping specific parameter? On Windows that would be "-t".
How about we add --nonstop/-t ? And if enabled the CLI will:
- Set max packet limit
- Once it gets close to the last packet, maybe before the last one, it will start a new measurement on the background and then stitch the results together to emulate a single continuous test.
Additionally:
- Document in readme and cli help
- Explore how easy it would be to implement the same for the mtr test.
- Note that in the future once we have a credits system, we need to make it clear that this parameter will keep eating credits non-stop
continuous is the word generally used for this, so that might be the best name, but it's a little hard to type - but with autocomplete, that might be fine? Alternatively I would suggest --infinite as you used in the issue title instead of non-stop.
As for -t, it might be familiar to Windows users but not Linux/Mac since continuous is the default there, and -t is used for TTL instead. In this case, I'd suggest just not adding the alias.
Once it gets close to the last packet, maybe before the last one, it will start a new measurement on the background and then stitch the results together to emulate a single continuous test.
Something like this makes sense but will need testing, maybe it'll need to be started a bit sooner.
Also, note that this should error out when combined with --json or --latency
continuous is the word generally used for this, so that might be the best name, but it's a little hard to type - but with autocomplete, that might be fine? Alternatively I would suggest --infinite as you used in the issue title instead of non-stop.
Yes, its too hard to type, thats why I used non-stop, but infinite works too.
Then with that change this task seems ready
Ready but the API will accept these requests only after jsdelivr/globalping#453 is merged.
@jimaek
1/ if I understand this correctly, the "--infinite" option runs a first probe and prints measurements as usual, but instead of exiting afterwards, it will run another probe using the id from the first probe and then it prints the new results ? Do you think it's compatible with the "live view" we currently have ? As a reminder the way the "live view" works is by continuously replacing the results from the screen with the temporary results, then at the end it deletes the temporary results and prints everything. So if we run a second probe it might look quite confusing to the user .
2/ what does "max packet limit" mean ?
3/ I'm not sure I understand what "stitch the results together to emulate a single continuous test" means here
- Yes its similar to the refreshing we do now, but when --infinite is enabled then the test never finishes, it will keep running until the user kills it. Just like if you run "ping google.com" on your mac/linux. The difference is that before the first measurement finishes we start a new one, providing the ID of the previous one as location, transparently from the user, and continue refreshing the results. But I dont think I understood what part will look confusing to the user.
- Its our an API parameter when creating a measurement. Set it to max when infinite is used, I think its 16, but re-check the docs please.
- Go here https://api.globalping.io/demo/ and run ping from "magic:krakow+netia". Then take the ID of that test and run a new test but replace location with "magic:Loz2fKHcfgy2CLbz" (set your ID). You will get another ping output.
The goal is to stich together the outputs non-stop forever, to make the ping look like any other ping on linux
Maybe we can go with --repeat/-R and combine it with --interval/-I?
--repeat or -repeat 0 (infinite), --repeat 1, --repeat 2 ... --repeat N
and --interval 5s, interval 1m ...
I am not sure if people will get the --repeat option since non-stop ping is the default behavior on linux and mac. But I do like the --interval idea. It should be optional though, where by default is instant (whatever ms we decide works best) and not required and the user can overwrite it to some other value.
We could add both --infinite and --interval, but note that the implementation must be different for each of them.
For --infinite, the goal is to emulate default Linux behavior and make it seem like 1 continuous ping. To do that, we'll likely want to start a second measurement shortly before the first one finishes as @jimaek mentioned to avoid any visible delays in between,
--interval if added should really be just "wait for the measurement to finish, wait N seconds, run it again"
^ Sounds good to me. Just need to properly document the behavior in CLI and readme
Should we use the same view to display the results continuously or do you have something else in mind?
Example
globalping-cli ping google.com from USA,Germany --limit 2 --infinite
> NA, US, (SC), Charlotte, ASN:14615, Comporium, Inc
PING google.com (74.125.138.113) 56(84) bytes of data.
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=1 ttl=55 time=8.33 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=2 ttl=55 time=7.23 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=3 ttl=55 time=7.42 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=4 ttl=55 time=7.42 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=5 ttl=55 time=7.63 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=6 ttl=55 time=7.87 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=7 ttl=55 time=8.11 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=8 ttl=55 time=7.54 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=9 ttl=55 time=8.35 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=10 ttl=55 time=8.36 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=11 ttl=55 time=8.07 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=12 ttl=55 time=8.23 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=13 ttl=55 time=7.99 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=14 ttl=55 time=7.66 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=15 ttl=55 time=7.50 ms
64 bytes from yi-in-f113.1e100.net (74.125.138.113): icmp_seq=16 ttl=55 time=8.09 ms
--- google.com ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 3019ms
rtt min/avg/max/mdev = 7.228/7.861/8.357/0.364 ms
> EU, DE, Falkenstein, ASN:24940, Hetzner Online GmbH
PING (142.250.185.174) 56(84) bytes of data.
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=1 ttl=116 time=4.92 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=2 ttl=116 time=4.95 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=3 ttl=116 time=4.93 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=4 ttl=116 time=4.85 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=5 ttl=116 time=4.88 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=6 ttl=116 time=4.91 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=7 ttl=116 time=4.87 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=8 ttl=116 time=4.87 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=9 ttl=116 time=4.87 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=10 ttl=116 time=4.91 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=11 ttl=116 time=4.85 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=12 ttl=116 time=4.86 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=13 ttl=116 time=4.88 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=14 ttl=116 time=4.94 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=15 ttl=116 time=4.91 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=16 ttl=116 time=4.92 ms
--- ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 3010ms
rtt min/avg/max/mdev = 4.849/4.895/4.949/0.031 ms
> NA, US, (SC), Charlotte, ASN:14615, Comporium, Inc
PING google.com (142.251.15.101) 56(84) bytes of data.
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=1 ttl=107 time=8.26 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=2 ttl=107 time=14.4 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=3 ttl=107 time=7.99 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=4 ttl=107 time=7.32 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=5 ttl=107 time=8.09 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=6 ttl=107 time=9.36 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=7 ttl=107 time=8.72 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=8 ttl=107 time=8.24 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=9 ttl=107 time=8.17 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=10 ttl=107 time=8.04 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=11 ttl=107 time=8.06 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=12 ttl=107 time=8.90 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=13 ttl=107 time=7.48 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=14 ttl=107 time=8.22 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=15 ttl=107 time=8.27 ms
64 bytes from yl-in-f101.1e100.net (142.251.15.101): icmp_seq=16 ttl=107 time=7.97 ms
--- google.com ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 3010ms
rtt min/avg/max/mdev = 7.317/8.590/14.373/1.565 ms
> EU, DE, Falkenstein, ASN:24940, Hetzner Online GmbH
PING (142.250.185.174) 56(84) bytes of data.
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=1 ttl=116 time=5.07 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=2 ttl=116 time=4.88 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=3 ttl=116 time=4.96 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=4 ttl=116 time=4.88 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=5 ttl=116 time=4.87 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=6 ttl=116 time=4.87 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=7 ttl=116 time=4.89 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=8 ttl=116 time=4.87 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=9 ttl=116 time=4.87 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=10 ttl=116 time=4.87 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=11 ttl=116 time=4.85 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=12 ttl=116 time=4.86 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=13 ttl=116 time=4.87 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=14 ttl=116 time=4.87 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=15 ttl=116 time=4.91 ms
64 bytes from fra16s51-in-f14.1e100.net (142.250.185.174): icmp_seq=16 ttl=116 time=4.89 ms
--- ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 3009ms
rtt min/avg/max/mdev = 4.854/4.892/5.066/0.050 ms Great question, @jimaek how do you expect this to work? For one probe, we could do the same as native ping, but for more than 1, it doesn't quite work and we need to keep updating the output that's in the visible part of the terminal.
One after the other is indeed not very useful. If the user requests more than 1 probe, can we collapse the UI to something else? Like only showing summaries per probe per row instead of the raw output. Basically a CLI output of this https://ping.pe/google.com
If we could get the users of similar sites as the one above to switch to our CLI and not feel a need to use the website it would be a huge win for us.