From BECHA at ripe.net Fri Feb 1 11:18:37 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 01 Feb 2013 11:18:37 +0100 Subject: [atlas] New release in January, features you asked for... Message-ID: <510B967D.9080500@ripe.net> Hi, we had a release 2 days ago, maybe you already noticed new features... * REST API -- althou in Beta! https://atlas.ripe.net/doc/rest * New costs for certain measurements: https://atlas.ripe.net/doc/credits & * 20 instead of 19 probes visualized in ping UDMs :) ... and if not, they are listed on RIPE Labs article: https://labs.ripe.net/Members/becha/ripe-atlas-january-2013-achievements ... and on the "announcements" page too: https://atlas.ripe.net/announce We are still working on "group access", and few more features are going to be announced to beta-testers soon. Share and enjoy! Regards, Vesna From bortzmeyer at nic.fr Fri Feb 1 12:44:02 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 1 Feb 2013 12:44:02 +0100 Subject: [atlas] New release in January, features you asked for... In-Reply-To: <510B967D.9080500@ripe.net> References: <510B967D.9080500@ripe.net> Message-ID: <20130201114402.GA12149@nic.fr> On Fri, Feb 01, 2013 at 11:18:37AM +0100, Vesna Manojlovic wrote a message of 27 lines which said: > * REST API -- althou in Beta! > https://atlas.ripe.net/doc/rest If I read the documentation correctly, it is only to *read* data. If so, what's the point? There was already a way to access data (download the JSON file and parse it) and I regret that it will be deprecated ("is intended to replace the current ways of programmatically accessing RIPE Atlas data"). What is really missing is a way to *run* measurements, specially with variable parameters (such as the QNAME for DNS UDMs). From robert at ripe.net Fri Feb 1 13:45:53 2013 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 01 Feb 2013 13:45:53 +0100 Subject: [atlas] New release in January, features you asked for... In-Reply-To: <20130201114402.GA12149@nic.fr> References: <510B967D.9080500@ripe.net> <20130201114402.GA12149@nic.fr> Message-ID: <510BB901.2030305@ripe.net> Stephane, On 2013.02.01. 12:44, Stephane Bortzmeyer wrote: > On Fri, Feb 01, 2013 at 11:18:37AM +0100, > Vesna Manojlovic wrote > a message of 27 lines which said: > >> * REST API -- althou in Beta! >> https://atlas.ripe.net/doc/rest > > If I read the documentation correctly, it is only to *read* data. If > so, what's the point? There was already a way to access data (download > the JSON file and parse it) and I regret that it will be deprecated > ("is intended to replace the current ways of programmatically > accessing RIPE Atlas data"). The API is also meant to allow listing measurements ("search"). The same API will make it possible to specify measurements. So, so far there was a way to access data, now there's also a way to access metadata, and a consistent way forward for more interaction with the system. > What is really missing is a way to *run* measurements, specially with > variable parameters (such as the QNAME for DNS UDMs). This is coming. As the article states: "We'll start testing two new features soon: one-off measurements and the measurement specification API to start and stop user-defined measurements. Beta testers will help us adjust these features before we go live with them." Regards, Robert From bortzmeyer at nic.fr Fri Feb 1 14:17:04 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 1 Feb 2013 14:17:04 +0100 Subject: [atlas] New release in January, features you asked for... In-Reply-To: <510BB901.2030305@ripe.net> References: <510B967D.9080500@ripe.net> <20130201114402.GA12149@nic.fr> <510BB901.2030305@ripe.net> Message-ID: <20130201131704.GA21171@nic.fr> On Fri, Feb 01, 2013 at 01:45:53PM +0100, Robert Kisteleki wrote a message of 31 lines which said: > As the article states: "We'll start testing two new features soon: > one-off measurements and the measurement specification API to start > and stop user-defined measurements. Just to be sure: this API will also allow to define new UDMs, not just start/stop existing ones? (I would like to run several slightly different UDMs sequentially) From astrikos at ripe.net Fri Feb 1 14:29:31 2013 From: astrikos at ripe.net (Andreas Strikos) Date: Fri, 1 Feb 2013 14:29:31 +0100 Subject: [atlas] New release in January, features you asked for... In-Reply-To: <20130201131704.GA21171@nic.fr> References: <510B967D.9080500@ripe.net> <20130201114402.GA12149@nic.fr> <510BB901.2030305@ripe.net> <20130201131704.GA21171@nic.fr> Message-ID: On Feb 1, 2013, at 2:17 PM, Stephane Bortzmeyer wrote: > On Fri, Feb 01, 2013 at 01:45:53PM +0100, > Robert Kisteleki wrote > a message of 31 lines which said: > >> As the article states: "We'll start testing two new features soon: >> one-off measurements and the measurement specification API to start >> and stop user-defined measurements. > > Just to be sure: this API will also allow to define new UDMs, not just > start/stop existing ones? (I would like to run several slightly > different UDMs sequentially) Yes you will be able to create new ones as well. Regards, Andreas From robert at ripe.net Mon Feb 4 12:58:22 2013 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 04 Feb 2013 12:58:22 +0100 Subject: [atlas] Partial downtime over the weekend Message-ID: <510FA25E.7050700@ripe.net> Dear all, On Friday we added the first devices of the upcoming next generation Atlas probes to our production network. Unfortunately, this triggered a bug in our controlling infrastructure, which resulted in some of the probes not being assigned any new measurements. Eventually, the affected probes ran out of measurement tasks. This bug affected about 30% of the probes approximately between Friday 23h and Sunday 12h (UTC). We apologise for any inconveniences this may cause. Regards, Robert Kisteleki RIPE Atlas team From BECHA at ripe.net Fri Feb 8 13:40:16 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 08 Feb 2013 13:40:16 +0100 Subject: [atlas] RIPE Atlas Community repository on GitHub Message-ID: <5114F230.1070509@ripe.net> Hi everyone, an appropriate pastime for Friday afternoon - playing with GitHub ;-) I initially created https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib for the contributions by you (and atlas-dev team) of the small programs, scripts, etc -- for visualizing RIPE Atlas measurements, analysing measurements data, and so on. We already had them listed here: https://atlas.ripe.net/doc/code However, GitHub seems to be *the* place for the community to exchange the code, so I am hoping that this repository will help share and maintain, and produce more code, and make it more useful for the rest of the world. First code in there is the one I inserted, created by Philip Homburg: "probes2kml.py", that shows probes on Google Earth. Please "add" more, or "link" your own contributions to this repository... ... or let me know how I can help to collect more of the RIPE Atlas specific code to this repository: from Wolfgang, Inigo, and others. Share and enjoy :) Regards, Vesna From BECHA at ripe.net Wed Feb 13 09:54:54 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 13 Feb 2013 09:54:54 +0100 Subject: [atlas] UDM destinations also visible in RIPEstat Message-ID: <511B54DE.8040901@ripe.net> Hi, I just wanted to share one more RIPE Atlas-related feature of RIPEstat: when querying for a IP prefix or AS number, you can now see all the UDMs that terminate in the IP addresses in that ASN or prefix, in the "Activity" tab, called "RIPE Atlas measurements targets". (picture attached) Below is a reminder of the feature to see all the probes, too. Happy measuring! Vesna -------- Original Message -------- Subject: [atlas] Atlas probes visible in RIPEstat Date: Fri, 21 Dec 2012 10:11:26 +0100 From: Vesna Manojlovic To: RIPE Atlas People Dear RIPE Atlas users, this might be of interest to you too -- it is now possible to see coverage of Atlas probes in any ASN, prefix or *country* in RIPEstat! It works both as a widget and as CLI: https://stat.ripe.net/widget/atlas-probes#w.resource=212/12 or whois -h stat.ripe.net AS3333 If you decide to embed this widget somewhere on your page, please do let us know, we like to see our work being used :) More interesting RIPEstat features in the article on RIPELabs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripestat-2012-december-update Cheers, Vesna -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 22.png Type: image/png Size: 316992 bytes Desc: not available URL: From BECHA at ripe.net Fri Feb 15 17:12:21 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 15 Feb 2013 17:12:21 +0100 Subject: [atlas] Phase 1 of RIPE Atlas Anchors pilot - report on RIPE Labs Message-ID: <511E5E65.9010002@ripe.net> Dear community, [apologies for the duplicates] we just published an article on RIPE Labs with the status & features available for the hosts of RIPE Atlas Anchor boxes after the Phase 1: https://labs.ripe.net/Members/becha/ripe-atlas-anchors-pilot-update-on-phase-one Share and enjoy :) Vesna From robert at ripe.net Mon Feb 18 13:23:26 2013 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 18 Feb 2013 13:23:26 +0100 Subject: [atlas] Warnings about running out of credits and runaway measurements Message-ID: <51221D3E.1070408@ripe.net> Dear Atlas users, Today we're going to enable two features that have been forecasted in the January 2013 Atlas update (https://labs.ripe.net/Members/becha/ripe-atlas-january-2013-achievements) Both of these features are intended to prevent runaway measurements which consume system resources, and to limit the resources used by users who don't contribute (any more) to the system; thus they both contribute to the stability and scalability of RIPE Atlas. They are both controlled by the credit system. The first feature is about sending warning emails if someone is about to run out of credits. That is, if the current credit consumption rate (with a two day lookback period) seems to use up all credits of a particular user within the next week or so, then we'll send an email about this. This allows the user to organise some extra credits, or stop some less important measurements in due time. The second feature stops measurements if someone actually runs out of credits. For now we'll use a *warning only* mode -- that is, the process will not actually stop measurements, it will only send emails. After a couple of weeks we'll change this to actually stop (some of the) measurements as well as notify the user. Our tests show that at the moment there are about a dozen people who would see effects of these processes. Both of these are necessary steps towards removing the existing limits imposed by the system (such as maximum amount of probes that can be used). Please let us know if you have questions or concerns, either on this mailing list, or (privately) by sending a mail to atlas at ripe.net Best regards, Robert Kisteleki RIPE Atlas team From dquinn at ripe.net Tue Feb 19 15:56:39 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Tue, 19 Feb 2013 15:56:39 +0100 Subject: [atlas] Notification regarding corrections to credit balances. Message-ID: <512392A7.4080202@ripe.net> Dear all, We'd like to inform you that we've recently discovered a bug in our accounting process that has caused some of you to be allocated fewer credits than you deserve. We've fixed the bug today. We are now calculating exactly how many credits have not been accounted for, and we will be crediting everyone's accounts accordingly. We apologise for the mix up, and if you have any questions, please feel free to ask. From BECHA at ripe.net Thu Feb 28 12:05:49 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 28 Feb 2013 12:05:49 +0100 Subject: [atlas] New version of probe firmware released: 4500 Message-ID: <512F3A0D.6090102@ripe.net> Dear probe hosts and community, few days ago we released the new version of RIPE Atlas probe firmware: 4500. These are the technical details: * RIPE Atlas probe software now supports two more architectures: TP-Link (for the next generation probes) and CentOS (for RIPE Atlas anchors). * There is now support for one-off measurements for ping, traceroute, DNS, and HTTPget. * We fixed a bug in DNS measurements in which, when querying local resolvers, more queries went to the last resolver. * Fixed "error" : { "TUCONNECT" : "Success"}. Before this version DNS TCP and HTTPget reported an error message "Success". When enough probes have been automatically upgaded to this new firmware, this will enable us to start testing the "one-off" or "near-real-time" measurements. We will enable this first for beta-testers, and after we fix the bugs reported by them, we will mae it available to all probe hosts, sponsors, and RIPE NCC members. Regards, Vesna