Questions with regard to the measurement status and running time
Hi RIPE Atlas Team and Community, I would like to know more about the status of measurements - I have scheduled a one-off ping measurement which utilized 15 anchors. I polled the measurement status and results from my local desktop to the restful API through cousteau Python lib. The results were returned to me in less than a minute, but it took around 13 minutes for the measurement to transition from "ongoing" to "stopped." On the other side, the time delta between the "requested start time" and "requested stop time" on the RIPE Atlas portal is 9 minutes. My questions are: 1. Why is the measurement "ongoing" even if the results have already been made available? 2. What is the meaning of the "requested start time" and "requested stop time" on the RIPE Atlas portal? 3. Will a one-off measurement release one slot from the measurement rate limit once its result becomes available even if it’s still in "ongoing" state? Thanks! Best, Jerome
Jerome,
My questions are: 1. Why is the measurement "ongoing" even if the results have already been made available?
One-off measurements are automatically marked "stopped" after 15 minutes by the system. This is mostly a book-keeping exercise to know what is active and what is not; it does not affect the flow of results.
2. What is the meaning of the "requested start time" and "requested stop time" on the RIPE Atlas portal?
The intention is to be able to pre-schedule a meeting into the future (for whatever reason you may have) instead of starting it asap, or to pre-determine its end if you already know when that should be. I believe the "start in future" is applicable to one-offs as well, stop time not so much (see above, they are auto-stopped).
3. Will a one-off measurement release one slot from the measurement rate limit once its result becomes available even if it’s still in "ongoing" state?
No, the measurement status is what counts. So such a slot is freed up after the msm is marked as stopped. We are considering a different book-keeping mechanism where the amount of results (activity) is used for quotas instead of number of measurements -- but this is not the case yet. We can adjust these limits, so if you have good reasons to do more (e.g. measurement campaign, bursts because of some research, etc.) then just let us know and we can help! Regards, Robert
Thanks! Best, Jerome
Thanks for the detailed response Robert! These are indeed very helpful! On Fri, Sep 8, 2023 at 12:41 AM Robert Kisteleki <robert@ripe.net> wrote:
Jerome,
My questions are: 1. Why is the measurement "ongoing" even if the results have already been made available?
One-off measurements are automatically marked "stopped" after 15 minutes by the system. This is mostly a book-keeping exercise to know what is active and what is not; it does not affect the flow of results.
2. What is the meaning of the "requested start time" and "requested stop time" on the RIPE Atlas portal?
The intention is to be able to pre-schedule a meeting into the future (for whatever reason you may have) instead of starting it asap, or to pre-determine its end if you already know when that should be. I believe the "start in future" is applicable to one-offs as well, stop time not so much (see above, they are auto-stopped).
3. Will a one-off measurement release one slot from the measurement rate limit once its result becomes available even if it’s still in "ongoing" state?
No, the measurement status is what counts. So such a slot is freed up after the msm is marked as stopped. We are considering a different book-keeping mechanism where the amount of results (activity) is used for quotas instead of number of measurements -- but this is not the case yet.
We can adjust these limits, so if you have good reasons to do more (e.g. measurement campaign, bursts because of some research, etc.) then just let us know and we can help!
Regards, Robert
Thanks! Best, Jerome
Hi Robert, We are formulating our request for increased measurement limits for our experiment. To help with our planning, what would be a reasonable rate of ping measurements from an single anchor to different targets? Specifically, we need to ping 1M targets, with each measurement involving three pings, so to complete the experiment in one day, this would translate into (1M*3 = 3M pings)/(24*3600 secs in a day) = ~35 pings per sec. This would obviously be nothing for a regular server, but would this be an issue for an anchor? (The rest of our measurement limit needs would flow from this data point). Thanks, Misha
On Sep 8, 2023, at 3:41 AM, Robert Kisteleki <robert@ripe.net> wrote:
Jerome,
My questions are: 1. Why is the measurement "ongoing" even if the results have already been made available?
One-off measurements are automatically marked "stopped" after 15 minutes by the system. This is mostly a book-keeping exercise to know what is active and what is not; it does not affect the flow of results.
2. What is the meaning of the "requested start time" and "requested stop time" on the RIPE Atlas portal?
The intention is to be able to pre-schedule a meeting into the future (for whatever reason you may have) instead of starting it asap, or to pre-determine its end if you already know when that should be. I believe the "start in future" is applicable to one-offs as well, stop time not so much (see above, they are auto-stopped).
3. Will a one-off measurement release one slot from the measurement rate limit once its result becomes available even if it’s still in "ongoing" state?
No, the measurement status is what counts. So such a slot is freed up after the msm is marked as stopped. We are considering a different book-keeping mechanism where the amount of results (activity) is used for quotas instead of number of measurements -- but this is not the case yet.
We can adjust these limits, so if you have good reasons to do more (e.g. measurement campaign, bursts because of some research, etc.) then just let us know and we can help!
Regards, Robert
Thanks! Best, Jerome
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
participants (3)
-
Jerome Mao -
Michael Rabinovich -
Robert Kisteleki