Hi Stephen, 

Thank you so much for your insightful advice. After specifying UDP in my API, the success rate has noticeably improved, with 7 out of 12 measurements returning the expected results. As there are still failed measurements, I repeated the test several times with a 10-second interval between two measurements, while each time there are 5 to 6 random measurements failed, showing the "specified" status. I then attempted to re-issue a measurement whenever the original one failed, and it seems that no more than three attempts are needed to obtain a successful measurement for a designated source and destination.

Although the issue appears to be resolved, I am still curious about the origin of the "specified" status. According to the Atlas documentation, "specified" refers to a state in which "the measurement has been defined and sent to the infrastructure to be relayed to the probes." However, based on my experiment, once a measurement enters the "specified" state, it stays there for an extended period and eventually transitions to "scheduling denied."

Thanks again for your precious help!

Best regard,

Sun

-----Original Messages-----
From: "Stephen Suess" <ssuess@ripe.net>
Send time: Thursday, 12/19/2024 18:48:27
To: 孙乐童 <slt20@mails.tsinghua.edu.cn>
Cc: ripe-atlas@ripe.net
Subject: [atlas] Re: Why measurements using api are apt to fail while those using web interface can usually succeed?

Hi again Sun,

The most obvious difference is that the UI measurements are using UDP (vs your api specified ICMP), so I believe this is what causes the difference. Try some of your API spec'd msms over UDP (if you are able) and I assume they will be successful as they are in the UI.

Hope this helps.

Kind regards, 

Stephen

Atlas UI

On Dec 19, 2024, at 8:46 AM, 孙乐童 <slt20@mails.tsinghua.edu.cn> wrote:

Thank you very much for your attention. I collect some measurements below:

description  | msm-id via UI | msm-id via API

________________________________________________________________________________________________________

select a probe from AS55699 and traceroute to 117.54.52.6 |    84972798  |    84952226
select a probe from AS141082 and traceroute to 117.54.52.6|    84972804 |  84952169
select a probe from AS45305 and traceroute to 117.54.52.6 |   84972821 |  84952193
select a probe from AS142360 and traceroute to 117.54.52.6|   84972826 |  84952233
select a probe from AS18106 and traceroute to 117.54.52.6 |   84972892 |  84952216
select a probe from AS24213 and traceroute to 117.54.52.6 |   84972907 |  84952182
select a probe from AS140423 and traceroute to 117.54.52.6|   84972912 |  84952198
select a probe from AS142348 and traceroute to 117.54.52.6|   84972917 |  84952221

-----Original Messages-----
From: "Stephen Suess" <ssuess@ripe.net>
Send time: Thursday, 12/19/2024 15:14:51
To: 孙乐童 <slt20@mails.tsinghua.edu.cn>
Cc: ripe-atlas@ripe.net
Subject: Re: [atlas] Why measurements using api are apt to fail while those using web interface can usually succeed?

Hi Sun,

If you could provide us a few of the measurement IDs for the ones that worked via the UI, along with a few IDs from the API created ones, we would be happy to take a look and see if we can determine the cause. You can include them here on the mailing list or send them to my email directly.

Kind Regards,

Stephen

Atlas UI

On Dec 19, 2024, at 4:22 AM, 孙乐童 <slt20@mails.tsinghua.edu.cn> wrote:

Dear all,

I have been attempting to use Atlas to launch traceroute measurements recently. Initially, I used ripe.atlas.cousteau to run the measurements in batches, keeping the total number under 10,000 to avoid exceeding the measurement limit. However, only 10% of the measurements returned successful results, while the other 90% showed the status "scheduling denied."

Next, I tried launching only 12 measurements in batch, where each measurement contained one traceroute from a specific probe to a designated IPv4 destination. Out of these, 4 succeeded and the other 8 showed the status "specified". Following that, I launched the 12 measurements one by one with 2-second intervals, resulting in a success rate of 6 out of 12. However, when I increased the interval to 3 seconds, the success rate dropped to 4 out of 12.

Interestingly, when I created the same measurements for the designated probes and destinations through the web interface, all of them were successful.

Below is the Python code I used to launch the measurements:

from ripe.atlas.cousteau import (

  Traceroute,

  AtlasSource,

  AtlasRequest,

  AtlasCreateRequest,

  AtlasResultsRequest,

  AtlasLatestRequest,

  ProbeRequest  

)

    traceroute = Traceroute(af=4, target=dstip, description="traceroute subpref ip {} from {} {}".format(dstip, probe_type, probe_value), protocol='ICMP')

    if probe_type == 'asn': probe_value = int(probe_value)

    source = AtlasSource(type=probe_type, value=probe_value, requested=1, tags={"include": ["system-ipv4-capable"]})

   

    _key = ATLAS_API_KEY_2

    for _ in range(2):

        atlas_request = AtlasCreateRequest(

            start_time=datetime.utcnow() + timedelta(random.randint(0, 1)),

            key=_key,

            measurements=[traceroute],

            sources=[source],

            is_oneoff=True

        )    

        (is_success, response) = atlas_request.create()

        if is_success:

            print('create_task', dstip, is_success, response)

            msm_id = response['measurements'][0]

            return

Could you kindly let me know if there might be an issue with my approach or provide any advice on how to improve this process? I would greatly appreciate any guidance.

Thank you very much!

Best regards,
Sun Letong

-----
To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. 
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/