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.
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
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
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
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
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
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.
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.
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
M1running.GET /M1 call returns:
The output is:
GET /M1 call returns:
Probe
PLfinished, so another measurementM2starts.M1is still running.3.1. GET /M1 call returns (no change):
3.2. GET /M2 call returns:
Probe
SKfinished inM2but is still running inM1, probeCZis running in both measurements, probePLis still running inM2. We are NOT starting a new measurement.5.1. GET /M1 call returns:
5.2. GET /M2 call returns (no change):
Probe
SKfinished in both measurements, soM3starts.M2is still running.Here it's also a question of what to show as
lastbecause M2 was started "later" but didn't have any updates and only M1 updated in this step. To simplify, let's saylastalways refers to the value from the most recently started measurement, in this case M2._Originally posted by @MartinKolarik in https://github.com/jsdelivr/globalping-cli/pull/86#discussion_r1476076822_