Infinite ping improvement

[MartinKolarik]

Seems that the wrong numbers issue got resolved, but we lost the concurrent calls in the process and wait for the measurement to fully finish before starting a new one.

The goal is still to start a second measurement as soon as any of the probe finishes so that for each probe, there is at least one measurement where that probe is currently running.

Here is a test scenario that you can add to the automated tests if not too hard, or at least use it to understand the intended behavior better. The numbers are somewhat unrealistic but it's just to demonstrate the behavior in a small number of steps.

ping 1.1.1.1 from SK,CZ,PL --limit 3 --infinite

There is one probe in each location, so "SK" below means "the probe that was selected for SK", etc... We start with a single measurement M1 running.

1. GET /M1 call returns:

SK: 12 sent, 12 received, 10 RTT for each packet
CZ: 14 sent, 14 received, 20 RTT for each packet
PL: 15 sent, 15 received, 30 RTT for each packet

2. The output is:

Location  | Sent |    Loss |     Last |      Min |      Avg |      Max
EU, SK... |   12 |   0.00% |  10.0 ms |  10.0 ms |  10.0 ms |  10.0 ms
EU, CZ... |   14 |   0.00% |  20.0 ms |  20.0 ms |  20.0 ms |  20.0 ms
EU, PL... |   15 |   0.00% |  30.0 ms |  30.0 ms |  30.0 ms |  30.0 ms

3. GET /M1 call returns:

SK: 12 sent, 12 received, 10 RTT for each packet
CZ: 14 sent, 14 received, 20 RTT for each packet
PL: 16 sent, 16 received, 30 RTT for the first 15 packets, 62 RTT for the last packet

2. The output is:

Location  | Sent |    Loss |     Last |      Min |      Avg |      Max
EU, SK... |   12 |   0.00% |  10.0 ms |  10.0 ms |  10.0 ms |  10.0 ms
EU, CZ... |   14 |   0.00% |  20.0 ms |  20.0 ms |  20.0 ms |  20.0 ms
EU, PL... |   16 |   0.00% |  62.0 ms |  30.0 ms |  32.0 ms |  62.0 ms

Probe PL finished, so another measurement M2 starts. M1 is still running.

3.1. GET /M1 call returns (no change):

SK: 12 sent, 12 received, 10 RTT for each packet
CZ: 14 sent, 14 received, 20 RTT for each packet
PL: 16 sent, 16 received, 30 RTT for the first 15 packets, 62 RTT for the last packet

3.2. GET /M2 call returns:

SK: 16 sent, 16 received, 17 RTT for each packet
CZ: 14 sent, 14 received, 40 RTT for each packet
PL: 10 sent, 10 received, 40 RTT  for each packet

4. The output is:

Location  | Sent |    Loss |     Last |      Min |      Avg |      Max
EU, SK... |   28 |   0.00% |  17.0 ms |  10.0 ms |  14.0 ms |  17.0 ms
EU, CZ... |   28 |   0.00% |  40.0 ms |  20.0 ms |  30.0 ms |  40.0 ms
EU, PL... |   26 |   0.00% |  40.0 ms |  30.0 ms |  35.1 ms |  62.0 ms

Probe SK finished in M2 but is still running in M1, probe CZ is running in both measurements, probe PL is still running in M2. We are NOT starting a new measurement.

5.1. GET /M1 call returns:

SK: 16 sent, 16 received, 10 RTT for each packet
CZ: 16 sent, 16 received, 20 RTT for each packet
PL: 16 sent, 16 received, 30 RTT for the first 15 packets, 62 RTT for the last packet

5.2. GET /M2 call returns (no change):

SK: 16 sent, 16 received, 17 RTT for each packet
CZ: 14 sent, 14 received, 40 RTT for each packet
PL: 10 sent, 10 received, 40 RTT for each packet

6. The output is:

Location  | Sent |    Loss |     Last |      Min |      Avg |      Max
EU, SK... |   32 |   0.00% |  17.0 ms |  10.0 ms |  13.5 ms |  17.0 ms
EU, CZ... |   30 |   0.00% |  40.0 ms |  20.0 ms |  29.3 ms |  40.0 ms
EU, PL... |   26 |   0.00% |  40.0 ms |  30.0 ms |  35.1 ms |  62.0 ms

Probe SK finished in both measurements, so M3 starts. M2 is still running.

Here it's also a question of what to show as last because M2 was started "later" but didn't have any updates and only M1 updated in this step. To simplify, let's say last always refers to the value from the most recently started measurement, in this case M2.

Originally posted by @MartinKolarik in #86 (comment)