Hi Wouter,
The status of one-offs is not related to results collected. The stopped
status is set by the timer after max 15 minutes. Since the measurement
scheduling is based on the best effort approach there cannot be 100%
guarantee that all the probes respond with the results so it becomes
quite difficult to set the stopped status when all probes finish
measuring. Moreover an additional lag can be introduced due to the
cluster processing. We saw situations when a measurement had the stopped
status but the results were coming.
So the workflow would be to start a measurement, allow it to be
scheduled and first results collected, then after 5-20 seconds you can
start polling it with the same or larger interval. The polling interval
should be the longer the more probes you use in your measurement.
Additionally you can estimate the data processing delay using the
https://atlas.ripe.net/api/v2/system/data-delay/ API call that shows the
lag in seconds and the latest received measurement timestamp.
If you want it to be truly synchronous you can use the streaming API. In
this case the results will be pushed to the client as soon as they are
coming from the probes.
WBR
/vty
On 6/18/19 8:08 PM, Wouter de Vries wrote:
Hi all,
I am currently trying to do some measurements according to the following
steps:
1. create a one-off measurement
2. wait for it to finish, by periodically polling the msmid and checking
the status.
3. fetch the results
However, the system takes a pretty long time to set the status to
finished, even when all results are already in (maybe 10 minutes?).
What heuristics/method do you recommend to determine whether to consider
a measurement as finished?
One option I consider is to periodically fetch all results for a given
msmid and checking if the number of results matches the number of probes
assigned to the measurement. However, I suspect that causes a much
higher load on the infrastructure.
Best regards,
Wouter de Vries
