RIPE Atlas User-Defined Measurements Are Here!
Dear Atlas Hosts and Sponsors, We are pleased to announce our first roll-out of user-defined measurements (UDM) for RIPE Atlas. As of today, all hosts and sponsors on this mailing list are invited to run custom measurements. Over the coming weeks we will continue to roll out UDM to a wider audience. To access UDM, either click on the link at the top right when you are logged in to the RIPE Atlas website, or go directly to: https://atlas.ripe.net/atlas/udm.html For the time being, we have created a fairly low rate limit, which we expect to increase over time. More information about limits and other aspects of the UDM system can be found in the documentation: https://atlas.ripe.net/doc/udm Discussion and questions about UDM can be directed to this mailing list (ripe-atlas@ripe.net) or to atlas-dev@ripe.net. You may also be interested in joining us at the UDM "Birds of a Feather" (BoF) session at RIPE 64 in Ljubljana, on Thursday, 19 April after the Measurements, Analysis and Tools (MAT) Working Group session. https://ripe64.ripe.net/programme/meeting-plan/bof/ Happy measuring! - The RIPE Atlas team
On 04/03/12 15:08, Ann Barcomb wrote:
We are pleased to announce our first roll-out of user-defined measurements (UDM) for RIPE Atlas.
Cool! Wishlist: To be able to schedule DNS queries. -- Marco
On 2012.04.03. 15:40, Marco Davids (SIDN) wrote:
On 04/03/12 15:08, Ann Barcomb wrote:
We are pleased to announce our first roll-out of user-defined measurements (UDM) for RIPE Atlas.
Cool!
Wishlist:
To be able to schedule DNS queries.
Rest assured, this is very high on our priority list! :-) Regards, Robert
* Ann Barcomb
We are pleased to announce our first roll-out of user-defined measurements (UDM) for RIPE Atlas. As of today, all hosts and sponsors on this mailing list are invited to run custom measurements. Over the coming weeks we will continue to roll out UDM to a wider audience.
Way cool! Some bugs/issues I noticed: 1) I first entered a traceroute UDM to olapaok.gr (ID 1001613). It got the description «Traceroute to 87.238.36.36(olapaok.gr)». The I entered a traceroute6 query to www.vg.no (ID 1001615). However, for some reason it ended up getting the same description as the first one. 2) One of the probes selected by the traceroute6 measurement (ID 863) does not have any IPv6 connectivity, if the info popup in the «Participants for UDM: 1001615» map is to be believed. 3) We host two probes with near-100% uptime. If I understand the documentation correctly, you get 15 credits per minute of uptime per probe, which should result in an daily income of ~42000 credits. However, the daily income is consistently ~14398. (Not that it is a problem, considering the current usage cap of 15000 credits/day.) 4) It's been half an hour since I submitted the measurements but still no results (scheduled them as ASAP). It would be nice if results started coming back a bit quicker - especially if I'm submitting a UDM for the purpose of debugging some ongoing connectivity problem. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
* Tore Anderson
Way cool!
Some bugs/issues I noticed:
And now that some results came back in for ID 1001613, I see another issue - the test result is presented as a single line, with the word «NEWLINE» appearing where you would expect there to be, well, an actual newline. There's also no way for me to scroll the browser frame horizontally in order to get to the end of the result, so I need to download the JSON file in order to view the full result. Also, the result suggests to me that UDP traceroute is being used. In my opinion, ICMP echo-request or even TCP/80 traceroutes are more useful these days, as they are more likely to reach their destination. Being able to select which type of packets are being used for tracerouting would be a nice feature to have. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
Hi Tore, On 4/3/12 4:26 PM, Tore Anderson wrote:
And now that some results came back in for ID 1001613, I see another issue - the test result is presented as a single line, with the word «NEWLINE» appearing where you would expect there to be, well, an actual newline. There's also no way for me to scroll the browser frame horizontally in order to get to the end of the result, so I need to download the JSON file in order to view the full result. Horizontal scrolling is enabled now.
WBR viktor naumov
Also, the result suggests to me that UDP traceroute is being used. In my opinion, ICMP echo-request or even TCP/80 traceroutes are more useful these days, as they are more likely to reach their destination. Being able to select which type of packets are being used for tracerouting would be a nice feature to have. Best regards, ICMP-based traceroutes are on the way. It may take a while because it requires upgrading the probes' firmware. At the moment we don't have
On 4/3/12 16:26 , Tore Anderson wrote: traceroutes based on TCP.
* Ann Barcomb
We are pleased to announce our first roll-out of user-defined measurements (UDM) for RIPE Atlas. As of today, all hosts and sponsors on this mailing list are invited to run custom measurements. Over the coming weeks we will continue to roll out UDM to a wider audience. Way cool!
Some bugs/issues I noticed:
1) I first entered a traceroute UDM to olapaok.gr (ID 1001613). It got the description «Traceroute to 87.238.36.36(olapaok.gr)». The I entered a traceroute6 query to www.vg.no (ID 1001615). However, for some reason it ended up getting the same description as the first one. Yes, if you had opened the form before some fields are cached and if you don't change them they will remain as they were before. We could try to change it if people don't want it at all. 2) One of the probes selected by the traceroute6 measurement (ID 863) does not have any IPv6 connectivity, if the info popup in the «Participants for UDM: 1001615» map is to be believed. This is a case where a probe for some reason has a v6 address but it not routed. Currently, if a probe has a v6 address we consider it as v6 enable. In the future we could be smarter and filter out these kind of cases. 3) We host two probes with near-100% uptime. If I understand the documentation correctly, you get 15 credits per minute of uptime per probe, which should result in an daily income of ~42000 credits. However, the daily income is consistently ~14398. (Not that it is a problem, considering the current usage cap of 15000 credits/day.) This changed today, from tomorrow on all of you will get the credits
Hi Tore, thanks for your fast feedback! See inline for answers. On 4/3/12 4:06 PM, Tore Anderson wrote: that specified in documentation.
4) It's been half an hour since I submitted the measurements but still no results (scheduled them as ASAP). It would be nice if results started coming back a bit quicker - especially if I'm submitting a UDM for the purpose of debugging some ongoing connectivity problem.
We are aware of this. It's already in our to-do list. For now, you can specify smaller frequency of you measurement so you will get it a bit earlier.
Best regards,
Regards, Andreas
* Andreas Strikos
On 4/3/12 4:06 PM, Tore Anderson wrote:
1) I first entered a traceroute UDM to olapaok.gr (ID 1001613). It got the description «Traceroute to 87.238.36.36(olapaok.gr)». The I entered a traceroute6 query to www.vg.no (ID 1001615). However, for some reason it ended up getting the same description as the first one. Yes, if you had opened the form before some fields are cached and if you don't change them they will remain as they were before.
The UDM description appears to be generated by the system. There is, as far as I can can tell, nowhere I can set a custom description when creating the UDM, nor can I change it after the UDM has been created.
4) It's been half an hour since I submitted the measurements but still no results (scheduled them as ASAP). It would be nice if results started coming back a bit quicker - especially if I'm submitting a UDM for the purpose of debugging some ongoing connectivity problem. We are aware of this. It's already in our to-do list. For now, you can specify smaller frequency of you measurement so you will get it a bit earlier.
Another thing I came to think of here is that it would be nice with the possibility to do a one-off measurement. I tried playing around with setting the End field to the past or immediately in the future, and the Interval really low, but it wouldn't let me add it because it incorrectly calculates that it would cost too many credits - it appears to be rounding up the duration of the UDM to 24 hours, I think. Also, it would be nice with a facility to search for probes, at least by ASN and country, so that you can find the perfect probe(s) to run a UDM from when debugging a specific problem. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
The new UDM is perfect. Thank you for that. I just would like to know if there is any security in place or planed to prevent the probe from connecting to sites that could bring me into trouble. Where I live this would only concern illegal sites/servers, but as we all know access to political sites are monitored in other countries by the government(e.g China). Olaf On 3 Apr 2012, at 21:35, Tore Anderson <tore.anderson@redpill-linpro.com> wrote:
* Andreas Strikos
On 4/3/12 4:06 PM, Tore Anderson wrote:
1) I first entered a traceroute UDM to olapaok.gr (ID 1001613). It got the description «Traceroute to 87.238.36.36(olapaok.gr)». The I entered a traceroute6 query to www.vg.no (ID 1001615). However, for some reason it ended up getting the same description as the first one. Yes, if you had opened the form before some fields are cached and if you don't change them they will remain as they were before.
The UDM description appears to be generated by the system. There is, as far as I can can tell, nowhere I can set a custom description when creating the UDM, nor can I change it after the UDM has been created.
4) It's been half an hour since I submitted the measurements but still no results (scheduled them as ASAP). It would be nice if results started coming back a bit quicker - especially if I'm submitting a UDM for the purpose of debugging some ongoing connectivity problem. We are aware of this. It's already in our to-do list. For now, you can specify smaller frequency of you measurement so you will get it a bit earlier.
Another thing I came to think of here is that it would be nice with the possibility to do a one-off measurement. I tried playing around with setting the End field to the past or immediately in the future, and the Interval really low, but it wouldn't let me add it because it incorrectly calculates that it would cost too many credits - it appears to be rounding up the duration of the UDM to 24 hours, I think.
Also, it would be nice with a facility to search for probes, at least by ASN and country, so that you can find the perfect probe(s) to run a UDM from when debugging a specific problem.
Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
* Olaf Maunz
I just would like to know if there is any security in place or planed to prevent the probe from connecting to sites that could bring me into trouble. Where I live this would only concern illegal sites/servers, but as we all know access to political sites are monitored in other countries by the government(e.g China).
As far as I can tell, TCP-based UDMs are currently not supported, so it is impossible to add a UDM that makes connections anywhere. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
On 2012.04.03. 23:22, Olaf Maunz wrote:
The new UDM is perfect. Thank you for that. I just would like to know if there is any security in place or planed to prevent the probe from connecting to sites that could bring me into trouble. Where I live this would only concern illegal sites/servers, but as we all know access to political sites are monitored in other countries by the government(e.g China).
Olaf
Hello, This makes me wonder if it would be useful to allow probe hosts to specify some kind of disclaimer for their probes? It would only make sense for public probes though. Another thing we have on our long-term todo list is to allow hosts to opt out from some measurement types / targets, so that the scheduler could take this into account when looking for vantage points for a UDM. I cannot give an ETA for this though. Regards, Robert
On 4/3/12 10:35 PM, Tore Anderson wrote:
* Andreas Strikos
On 4/3/12 4:06 PM, Tore Anderson wrote:
1) I first entered a traceroute UDM to olapaok.gr (ID 1001613). It got the description «Traceroute to 87.238.36.36(olapaok.gr)». The I entered a traceroute6 query to www.vg.no (ID 1001615). However, for some reason it ended up getting the same description as the first one. Yes, if you had opened the form before some fields are cached and if you don't change them they will remain as they were before. The UDM description appears to be generated by the system. There is, as far as I can can tell, nowhere I can set a custom description when creating the UDM, nor can I change it after the UDM has been created.
There is a last box in the form that allows you to edit and write your own description. Maybe is hidden because the form is too small for you. Try to maximize the UDM form and you will see it.
4) It's been half an hour since I submitted the measurements but still no results (scheduled them as ASAP). It would be nice if results started coming back a bit quicker - especially if I'm submitting a UDM for the purpose of debugging some ongoing connectivity problem. We are aware of this. It's already in our to-do list. For now, you can specify smaller frequency of you measurement so you will get it a bit earlier. Another thing I came to think of here is that it would be nice with the possibility to do a one-off measurement. I tried playing around with setting the End field to the past or immediately in the future, and the Interval really low, but it wouldn't let me add it because it incorrectly calculates that it would cost too many credits - it appears to be rounding up the duration of the UDM to 24 hours, I think. This is asked by several of you so we are already working on it. It should be out soon. Also, it would be nice with a facility to search for probes, at least by ASN and country, so that you can find the perfect probe(s) to run a UDM from when debugging a specific problem. These pages might help you with this until we give a search option. https://atlas.ripe.net/contrib/coverage.html https://atlas.ripe.net/atlas/prb_coverage.html?asn_v6=[as number] Same logic for asn_v4,prefix_v4, prefix_v6, country But it's a good idea, it's worth implementing at some point.
Best regards, Regards, Andreas
* Andreas Strikos
There is a last box in the form that allows you to edit and write your own description. Maybe is hidden because the form is too small for you. Try to maximize the UDM form and you will see it.
If I haven't gone blind, the last box in the form is «Do not visualise». See attachment.
These pages might help you with this until we give a search option. https://atlas.ripe.net/contrib/coverage.html https://atlas.ripe.net/atlas/prb_coverage.html?asn_v6=[as number] Same logic for asn_v4,prefix_v4, prefix_v6, country
Perfect, thanks! Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
On 04/04/2012 11:02, Tore Anderson wrote:
* Andreas Strikos
There is a last box in the form that allows you to edit and write your own description. Maybe is hidden because the form is too small for you. Try to maximize the UDM form and you will see it. If I haven't gone blind, the last box in the form is «Do not visualise». See attachment. You have gone blind :P . Make the conf box bigger. Or you hit a browser dependent bug.
These pages might help you with this until we give a search option. https://atlas.ripe.net/contrib/coverage.html https://atlas.ripe.net/atlas/prb_coverage.html?asn_v6=[as number] Same logic for asn_v4,prefix_v4, prefix_v6, country Perfect, thanks!
Best regards,
* Kyriacos Sakkas
You have gone blind :P . Make the conf box bigger. Or you hit a browser dependent bug.
Indeed. :-) I think this must be a browser-dependent bug. If I clear my cookies and cache and log in, and open the new measurement form, the default-sized box does not show the description field (even though my browser window is maximised and have ample vertical space). Also, there are no visual clues that would lead me to suspect that the default box isn't full-sized and that there are hidden fields that may be uncovered by resizing it. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
On /4/42012 10:26 , Tore Anderson wrote:
* Kyriacos Sakkas
You have gone blind :P . Make the conf box bigger. Or you hit a browser dependent bug.
Indeed. :-)
I think this must be a browser-dependent bug. If I clear my cookies and cache and log in, and open the new measurement form, the default-sized box does not show the description field (even though my browser window is maximised and have ample vertical space). Also, there are no visual clues that would lead me to suspect that the default box isn't full-sized and that there are hidden fields that may be uncovered by resizing it.
Best regards,
Hi, We've discovered that this does appear to be a browser-specific bug. I don't see the description in Firefox but I do see it in Chrome. As a temporary work-around, you can manually increase the length of the box. I have added details about this in the documentation to address the issue until we have the opportunity to solve the problem. Kind Regards, Ann -- Ann Barcomb RIPE NCC Community Builder http://www.ripe.net Measurements Community Building +31 20 535 4444
* Ann Barcomb
We've discovered that this does appear to be a browser-specific bug. I don't see the description in Firefox but I do see it in Chrome. As a temporary work-around, you can manually increase the length of the box.
Hi Ann, Actually, it was with Chrome (version 18.0.1025.142) I experienced this problem, not Firefox. I tried Firefox (verson 11.0) now, while the box is too small by default there too, the upper ~20% of the label and text input field is visible, so it is obvious that there's something there (unlike Chrome). I'm running Linux (Fedora 16), for what it's worth. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
On /4/42012 12:00 , Tore Anderson wrote:
* Ann Barcomb
We've discovered that this does appear to be a browser-specific bug. I don't see the description in Firefox but I do see it in Chrome. As a temporary work-around, you can manually increase the length of the box.
Hi Ann,
Actually, it was with Chrome (version 18.0.1025.142) I experienced this problem, not Firefox. I tried Firefox (verson 11.0) now, while the box is too small by default there too, the upper ~20% of the label and text input field is visible, so it is obvious that there's something there (unlike Chrome).
I'm running Linux (Fedora 16), for what it's worth.
Best regards,
In that case, I will mention that it is a problem with some browsers (in the documentation), and will leave it up to the developers to isolate the problem. Thanks for the update! - Ann -- Ann Barcomb RIPE NCC Community Builder http://www.ripe.net Measurements Community Building +31 20 535 4444
participants (9)
-
Andreas Strikos -
Ann Barcomb -
Kyriacos Sakkas -
Marco Davids (SIDN) -
Olaf Maunz -
Philip Homburg -
Robert Kisteleki -
Tore Anderson -
Viktor Naumov