From astracha at ripe.net Tue Sep 8 14:50:10 2015 From: astracha at ripe.net (Alastair Strachan) Date: Tue, 8 Sep 2015 14:50:10 +0200 Subject: [atlas] Booking.com (Frankfurt DE, Hong Kong and Ashbury US) have joined the RIPE Atlas Anchors Message-ID: <283913FD-DD86-458A-B6AE-826779D12DB2@ripe.net> Dear RIPE Atlas users, We're happy to announce that three more RIPE Atlas anchors have joined the network and are now available as targets for probe hosts conducting their own user-defined measurements. The new anchors are all hosted by Booking.com: de-fra-as43996, in Frankfurt (Germany) hk-hkg-as43996 in Hong Kong (Hong Kong) us-abn-as43996 in Ashburn (US) Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards these anchors from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From alexandre.abreu at vodafone.com Tue Sep 8 17:06:48 2015 From: alexandre.abreu at vodafone.com (Abreu, Alexandre, Vodafone Portugal) Date: Tue, 8 Sep 2015 15:06:48 +0000 Subject: [atlas] Probe management sharing - LIR Message-ID: <8DC8F21627983444A6CB959F6DCFBD75985CFF44@VOEXM06W.internal.vodafone.com> Hi all I've shared the management of my probes using the LIR option. It worked fine for 2 LIR users (one of them is me and I now see the probes as "mine" and "shared with me") but one other LIR user doesn't see anything unless I specify his username explicitly. What kind of users are these? Aren't these the LIR users we can add on the LIR portal? Thanks in advance. Alexandre Abreu -------------- next part -------------- An HTML attachment was scrubbed... URL: From elane at ripe.net Fri Sep 11 12:53:08 2015 From: elane at ripe.net (Eamonn Lane) Date: Fri, 11 Sep 2015 12:53:08 +0200 Subject: [atlas] us-mia-as33280, Afilias Miami has joined RIPE Atlas anchors Message-ID: <2E78C860-9FDB-4197-93B1-0F24CB76BBC4@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called us-mia-as33280 and is hosted by Afilias in Miami , USA. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2598 bytes Desc: not available URL: From elane at ripe.net Fri Sep 11 12:53:48 2015 From: elane at ripe.net (Eamonn Lane) Date: Fri, 11 Sep 2015 12:53:48 +0200 Subject: [atlas] Leaseweb Network B.V. in Haarlem, The Netherlands has joined Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called nl-haa-as60781 and is hosted by Leaseweb Network B.V. in Haarlem, The Netherlands. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.ne -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2598 bytes Desc: not available URL: From me at anuragbhatia.com Tue Sep 15 14:57:20 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 15 Sep 2015 18:27:20 +0530 Subject: [atlas] Question about "location setting" of RIPE Atlas In-Reply-To: <55DACA9C.40207@ripe.net> References: <55DACA9C.40207@ripe.net> Message-ID: Thanks for replies everyone! I completely agree to what you are saying and I think Tomas hits it right saying that I anyway have 19ms latency hence result would be messy. So no over thinking, I kept location as where Probe physically is and updated it with "point-to-point" tag. :) Thanks again for suggestions. On Mon, Aug 24, 2015 at 1:11 PM, Daniel Karrenberg < daniel.karrenberg at ripe.net> wrote: > Anurag, > > thanks for the good question. > > Please set the location as the physical location of the probe itself. We > need a common definition for this. If we all over-think and fudge this, > the data will become meaningless. Also Inigo's suggestions are good ones. > > Daniel > > On 22.08.15 23:42 , Anurag Bhatia wrote: > > I have been hosting one of RIPE probes and recently I have switched over > > my ISP. > > > > > > Basically my previous ISP provider was regular ISP network with full L3 > > PoPs nearby but in my new setup I have got a point to point to a city > > 900km away and getting IP transit over there. > > > > > > Now under such case, I am "technically" customer of that network. Should > > I still keep my location as I have current one or better update it to > > that new location 900km away? > > > > > > The latency of course is low (as it is provisioned on fiber and hence > > just 20ms roundtrip) but I think it will confuse off stats if anyone > > considers to use this probe for any data in my region. > > > > > > What you all think? Can someone recommend on correct location? > > > > > > > > Thanks. > > > > -- > > > > > > Anurag Bhatia > > anuragbhatia.com > > > > > > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 > > -- Anurag Bhatia anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vdijkstra at ripe.net Wed Sep 16 15:26:24 2015 From: vdijkstra at ripe.net (Valentino Dijkstra) Date: Wed, 16 Sep 2015 15:26:24 +0200 Subject: [atlas] TELUS in Montreal, Canada has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called ca-mtr-as852 and is hosted by TELUS in Montreal, Canada. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From BECHA at ripe.net Thu Sep 17 11:04:42 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 17 Sep 2015 11:04:42 +0200 Subject: [atlas] Last minute reminder: few more places left for the webinar today (for LIRs) In-Reply-To: <55D31F8F.8030408@ripe.net> References: <55D31F8F.8030408@ripe.net> Message-ID: <55FA822A.4010007@ripe.net> Dear colleagues, today, 1:30 PM Amsterdam time we are hosting, for the 3rd time, webinar on "Advanced RIPE Atlas Usage", aiming to teach network operators how to use RIPE Atlas measurements for network monitoring and troubleshooting. Register now at: https://lirportal.ripe.net/training/register/courseCode/WEB20150039 Web-registration is *only* possible for LIRs (RIPE NCC members). Dates for the several more webinars this year will be announced soon; non-members of RIPE NCC (people who do not have "Reg-ID") will be able then to email training @ ripe.net and be registered manually for. More details below. Regards, Vesna https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-atlas-usage-webinar This is part of the series of interactive on-line learning sessions, that give you the opportunity to learn and interact with trainers without leaving your desk, as well as for hands-on practice, and to get your questions answered by developers. Learn how to: - Use RIPE Atlas measurements for network monitoring and troubleshooting - Use API calls for measurement creation - Integrate RIPE Atlas with existing monitoring systems Webinars start at 11:30 UTC, and take about one hour. We look forward to seeing you online. Kind regards, Vesna Manojlovic RIPE NCC From jon.brewer at gmail.com Thu Sep 17 12:11:58 2015 From: jon.brewer at gmail.com (Jonathan Brewer) Date: Thu, 17 Sep 2015 22:11:58 +1200 Subject: [atlas] Downloading ad-hoc Atlas measurements as JSON Message-ID: Hi All, One of my current frustrations is that when downloading ad-hoc Atlas measurements, the file name is always the same: "RIPE-Atlas-measurement.json". This is unfortunate. It would be great if the web server would by default call this measurement by its ID. Anyone else experiencing this problem? Regards, Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From BECHA at ripe.net Thu Sep 17 12:14:09 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 17 Sep 2015 12:14:09 +0200 Subject: [atlas] Downloading ad-hoc Atlas measurements as JSON In-Reply-To: References: Message-ID: <55FA9271.2060408@ripe.net> Hi, sounds like a good idea, we'll add it to the roadmap! Thanks, Vesna On 17-sep.-15 12:11, Jonathan Brewer wrote: > Hi All, > > One of my current frustrations is that when downloading ad-hoc Atlas > measurements, the file name is always the same: > "RIPE-Atlas-measurement.json". This is unfortunate. It would be great if > the web server would by default call this measurement by its ID. > > Anyone else experiencing this problem? > > Regards, > > Jon From bortzmeyer at nic.fr Thu Sep 17 15:22:49 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 17 Sep 2015 15:22:49 +0200 Subject: [atlas] Strange 500 submission error In-Reply-To: <20150917131751.GA13288@nic.fr> References: <20150917131751.GA13288@nic.fr> Message-ID: <20150917132249.GA13560@nic.fr> On Thu, Sep 17, 2015 at 03:17:51PM +0200, Stephane Bortzmeyer wrote a message of 26 lines which said: > Atlas' API sends me back HTML pages :-) Same problem on : Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator at atlas-dev at ripe.net to inform them of the time this error occurred, and the actions you performed just before this error. More information about this error may be available in the server error log. Apache Server at atlas.ripe.net Port 443 From bortzmeyer at nic.fr Thu Sep 17 15:17:51 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 17 Sep 2015 15:17:51 +0200 Subject: [atlas] Strange 500 submission error Message-ID: <20150917131751.GA13288@nic.fr> Atlas' API sends me back HTML pages :-) RIPEAtlas.RequestSubmissionError: Status 500, reason " - RIPE Atlas — RIPE Network Coordination Centre ... From robert at ripe.net Thu Sep 17 15:33:01 2015 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 17 Sep 2015 15:33:01 +0200 Subject: [atlas] Strange 500 submission error In-Reply-To: <20150917132249.GA13560@nic.fr> References: <20150917131751.GA13288@nic.fr> <20150917132249.GA13560@nic.fr> Message-ID: <55FAC10D.8060303@ripe.net> On 2015-09-17 15:22, Stephane Bortzmeyer wrote: > On Thu, Sep 17, 2015 at 03:17:51PM +0200, > Stephane Bortzmeyer wrote > a message of 26 lines which said: > >> Atlas' API sends me back HTML pages :-) > > Same problem on : > > Internal Server Error > > The server encountered an internal error or misconfiguration and was unable to complete your request. > > Please contact the server administrator at atlas-dev at ripe.net to inform them of the time this error occurred, and the actions you performed just before this error. > > More information about this error may be available in the server error log. > Apache Server at atlas.ripe.net Port 443 Hi, The backend team is doing database migrations, which is taking longer than expected. We should be back up shortly. Cheers, Robert From mm at 42com.com Thu Sep 17 15:21:32 2015 From: mm at 42com.com (=?UTF-8?Q?Max_M=c3=bchlbronner?=) Date: Thu, 17 Sep 2015 15:21:32 +0200 Subject: [atlas] Ripe-Atlas 500 Internal Server Error ? Message-ID: <55FABE5C.10605@42com.com> Hi, Atlas is not working right now. (500 Internal Server Eror) Same from different locations/networks. But i guess you already noticed? Best Regards -- Max M?hlbronner 42com Telecommunication GmbH Stra?e der Pariser Kommune 12-16 10243 Berlin E-Mail: mm at 42com.com Web: www.42com.com Firmenangaben/Company information: Handelsregister/Commercial register: Amtsgericht Berlin HRB 99071 B Umsatzsteuer-ID/VAT-ID: DE223812306 Gesch?ftsf?hrer/CEO: Thomas Reinig, Alexander Reinig Diese E-Mail enth?lt Informationen von 42com Telecommunication GmbH. Diese sind m?glicherweise vertraulich und ausschlie?lich f?r den Adressaten bestimmt. Sollten Sie diese elektronische Nachricht irrt?mlicherweise erhalten haben, so informieren Sie uns bitte unverz?glich telefonisch oder per E-Mail. This message is intended only for the use of the individual or entity to which it is addressed. If you have received this message by mistake, please notify us immediately. From colinj at mx5.org.uk Thu Sep 17 15:44:54 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Thu, 17 Sep 2015 14:44:54 +0100 Subject: [atlas] Strange 500 submission error In-Reply-To: <55FAC10D.8060303@ripe.net> References: <20150917131751.GA13288@nic.fr> <20150917132249.GA13560@nic.fr> <55FAC10D.8060303@ripe.net> Message-ID: <838932F0-59DD-4B1E-8CE3-5E2E031191F4@mx5.org.uk> Hi Robert, is the maint/outage list for the service we can subscribe to be made aware of service problems ? Colin > On 17 Sep 2015, at 14:33, Robert Kisteleki wrote: > > On 2015-09-17 15:22, Stephane Bortzmeyer wrote: >> On Thu, Sep 17, 2015 at 03:17:51PM +0200, >> Stephane Bortzmeyer wrote >> a message of 26 lines which said: >> >>> Atlas' API sends me back HTML pages :-) >> >> Same problem on : >> >> Internal Server Error >> >> The server encountered an internal error or misconfiguration and was unable to complete your request. >> >> Please contact the server administrator at atlas-dev at ripe.net to inform them of the time this error occurred, and the actions you performed just before this error. >> >> More information about this error may be available in the server error log. >> Apache Server at atlas.ripe.net Port 443 > > Hi, > > The backend team is doing database migrations, which is taking longer than > expected. We should be back up shortly. > > Cheers, > Robert > From bortzmeyer at nic.fr Thu Sep 17 15:44:28 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 17 Sep 2015 15:44:28 +0200 Subject: [atlas] Ripe-Atlas 500 Internal Server Error ? In-Reply-To: <55FABE5C.10605@42com.com> References: <55FABE5C.10605@42com.com> Message-ID: <20150917134428.GA17169@nic.fr> On Thu, Sep 17, 2015 at 03:21:32PM +0200, Max M?hlbronner wrote a message of 37 lines which said: > Atlas is not working right now. (500 Internal Server Eror) It seems back now (Web site and API). From robert at ripe.net Thu Sep 17 15:48:07 2015 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 17 Sep 2015 15:48:07 +0200 Subject: [atlas] Strange 500 submission error In-Reply-To: <838932F0-59DD-4B1E-8CE3-5E2E031191F4@mx5.org.uk> References: <20150917131751.GA13288@nic.fr> <20150917132249.GA13560@nic.fr> <55FAC10D.8060303@ripe.net> <838932F0-59DD-4B1E-8CE3-5E2E031191F4@mx5.org.uk> Message-ID: <55FAC497.10308@ripe.net> On 2015-09-17 15:44, Colin Johnston wrote: > Hi Robert, is the maint/outage list for the service we can subscribe to be made aware of service problems ? > > Colin Hi, This is that list ;-) We expected the downtime to be virtually not noticeable, so there was no such announcement. Excuses for the issue; we should be back in business now. Regards, Robert From bortzmeyer at nic.fr Thu Sep 17 16:23:28 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 17 Sep 2015 16:23:28 +0200 Subject: [atlas] Strange 500 submission error In-Reply-To: <55FAC497.10308@ripe.net> References: <20150917131751.GA13288@nic.fr> <20150917132249.GA13560@nic.fr> <55FAC10D.8060303@ripe.net> <838932F0-59DD-4B1E-8CE3-5E2E031191F4@mx5.org.uk> <55FAC497.10308@ripe.net> Message-ID: <20150917142328.GA22811@nic.fr> On Thu, Sep 17, 2015 at 03:48:07PM +0200, Robert Kisteleki wrote a message of 14 lines which said: > we should be back in business now. No, there are still random 500 errors. From dquinn at ripe.net Thu Sep 17 16:28:08 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Thu, 17 Sep 2015 16:28:08 +0200 Subject: [atlas] Strange 500 submission error In-Reply-To: <20150917142328.GA22811@nic.fr> References: <20150917131751.GA13288@nic.fr> <20150917132249.GA13560@nic.fr> <55FAC10D.8060303@ripe.net> <838932F0-59DD-4B1E-8CE3-5E2E031191F4@mx5.org.uk> <55FAC497.10308@ripe.net> <20150917142328.GA22811@nic.fr> Message-ID: <55FACDF8.2090600@ripe.net> Can you send me (off-list) any URLs that are dropping 500s? It may be a caching issue, but I want to be sure. From randy at psg.com Fri Sep 18 05:50:12 2015 From: randy at psg.com (Randy Bush) Date: Fri, 18 Sep 2015 09:50:12 +0600 Subject: [atlas] Strange 500 submission error In-Reply-To: <55FAC497.10308@ripe.net> References: <20150917131751.GA13288@nic.fr> <20150917132249.GA13560@nic.fr> <55FAC10D.8060303@ripe.net> <838932F0-59DD-4B1E-8CE3-5E2E031191F4@mx5.org.uk> <55FAC497.10308@ripe.net> Message-ID: > We expected the downtime to be virtually not noticeable, so there was no > such announcement. now there is a classic telco ops email :) randy From robert at ripe.net Fri Sep 18 13:31:24 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 18 Sep 2015 13:31:24 +0200 Subject: [atlas] Data delays on RIPE Atlas Message-ID: <55FBF60C.9030705@ripe.net> Dear all, The data backend behind RIPE Atlas is experiencing some issues at the moment. This causes delays in processing and serving the data, meaning all results are delivered late. We're working on a fix. Excuses for the inconvenience. Regards, Robert From magicsata at gmail.com Fri Sep 18 14:09:16 2015 From: magicsata at gmail.com (Alistair Mackenzie) Date: Fri, 18 Sep 2015 13:09:16 +0100 Subject: [atlas] Data delays on RIPE Atlas In-Reply-To: <55FBF60C.9030705@ripe.net> References: <55FBF60C.9030705@ripe.net> Message-ID: Is this also effecting credits generated from probes? On 18 Sep 2015 12:31, "Robert Kisteleki" wrote: > Dear all, > > The data backend behind RIPE Atlas is experiencing some issues at the > moment. This causes delays in processing and serving the data, meaning all > results are delivered late. > > We're working on a fix. Excuses for the inconvenience. > > Regards, > Robert > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Fri Sep 18 15:13:50 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 18 Sep 2015 15:13:50 +0200 Subject: [atlas] Data delays on RIPE Atlas In-Reply-To: References: <55FBF60C.9030705@ripe.net> Message-ID: <55FC0E0E.9000207@ripe.net> On 2015-09-18 14:09, Alistair Mackenzie wrote: > Is this also effecting credits generated from probes? No, this is only a delay in delivering results. All other functions should be fine. Cheers, Robert > On 18 Sep 2015 12:31, "Robert Kisteleki" > wrote: > > Dear all, > > The data backend behind RIPE Atlas is experiencing some issues at the > moment. This causes delays in processing and serving the data, meaning all > results are delivered late. > > We're working on a fix. Excuses for the inconvenience. > > Regards, > Robert > From romeo.zwart at ripe.net Fri Sep 18 21:50:19 2015 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Fri, 18 Sep 2015 21:50:19 +0200 Subject: [atlas] Data delays on RIPE Atlas In-Reply-To: <55FBF60C.9030705@ripe.net> References: <55FBF60C.9030705@ripe.net> Message-ID: <55FC6AFB.1030703@ripe.net> Dear all, It took a few hours to identify the underlying problem and some more to consume the backlog of messages that had been created in the mean time. At the moment all backlogs have been cleared up and processing has returned to normal. Again apologies for the inconvenience. Kind regards, Romeo On 15/09/18 13:31 , Robert Kisteleki wrote: > Dear all, > > The data backend behind RIPE Atlas is experiencing some issues at the > moment. This causes delays in processing and serving the data, meaning all > results are delivered late. > > We're working on a fix. Excuses for the inconvenience. > > Regards, > Robert > > From romeo.zwart at ripe.net Sat Sep 19 09:32:57 2015 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Sat, 19 Sep 2015 09:32:57 +0200 Subject: [atlas] Data delays on RIPE Atlas In-Reply-To: <55FC6AFB.1030703@ripe.net> References: <55FBF60C.9030705@ripe.net> <55FC6AFB.1030703@ripe.net> Message-ID: Thanks to those who prompted me offline. :) There will of course be more info on what happened yesterday, but that will come after the weekend. Kind regards, Romeo > On 18 sep. 2015, at 21:50, Romeo Zwart wrote: > > Dear all, > It took a few hours to identify the underlying problem and some more to > consume the backlog of messages that had been created in the mean time. > At the moment all backlogs have been cleared up and processing has > returned to normal. > > Again apologies for the inconvenience. > > Kind regards, > Romeo > >> On 15/09/18 13:31 , Robert Kisteleki wrote: >> Dear all, >> >> The data backend behind RIPE Atlas is experiencing some issues at the >> moment. This causes delays in processing and serving the data, meaning all >> results are delivered late. >> >> We're working on a fix. Excuses for the inconvenience. >> >> Regards, >> Robert > > From bortzmeyer at nic.fr Mon Sep 21 15:16:44 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 21 Sep 2015 15:16:44 +0200 Subject: [atlas] [rfc-editor@rfc-editor.org: [lmap] RFC 7594 on A Framework for Large-Scale Measurement of Broadband Performance (LMAP)] Message-ID: <20150921131644.GB8431@nic.fr> We just need "millions" of Atlas to implement this vision :-) -------------- next part -------------- An embedded message was scrubbed... From: rfc-editor at rfc-editor.org Subject: [lmap] RFC 7594 on A Framework for Large-Scale Measurement of Broadband Performance (LMAP) Date: Fri, 18 Sep 2015 08:32:39 -0700 (PDT) Size: 8647 URL: From vdijkstra at ripe.net Tue Sep 22 14:48:54 2015 From: vdijkstra at ripe.net (Valentino Dijkstra) Date: Tue, 22 Sep 2015 14:48:54 +0200 Subject: [atlas] Booking.com IT Services, Singapore, as joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called nz-lyj-as17746 and is hosted by Booking.com IT Services, Singapore. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From vdijkstra at ripe.net Tue Sep 22 14:52:51 2015 From: vdijkstra at ripe.net (Valentino Dijkstra) Date: Tue, 22 Sep 2015 14:52:51 +0200 Subject: [atlas] Booking.com IT Services, Singapore has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called sg-sin-as43996 and is hosted by Booking.com IT Services, Singapore. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From romeo.zwart at ripe.net Tue Sep 22 17:34:10 2015 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Tue, 22 Sep 2015 17:34:10 +0200 Subject: [atlas] Friday's events on RIPE Atlas Message-ID: <560174F2.10408@ripe.net> Dear all, Here is a description of the events that took place last Friday and some 'lessons learned' that we took away from it. The high level summary of events is that an Atlas user was authorised to create an extreme number of measurements involving a large number of probes. This effectively overloaded the back-end machinery in various different ways. Even though this event could only happen because of the exception in resource use limits, we have implemented workarounds and countermeasures to avoid a repetition in future, and we will be investigating some of the more fundamental issues in the coming period. More information is available below for those interested. Observations: - Problems started shortly before 11am when one of the Atlas users created a large number of new measurements each involving all available probes. The user had been given an exceptional amount of credits as part of a special experiment. Therefore the normal limitations on the impact any individual user can have on the system were not active when the measurements were created and activated. - The results of the newly created measurements put a lot of strain on the measurement scheduler, which triggered our interest. After some investigation the cause of the overload was identified and the related measurements were ended. - However, by this time the majority of results, up to that moment, had already reached our queuing servers and the consumers were already ingesting the results into our Hadoop storage platform. - At this phase we discovered a capacity problem with the process that consumes the Atlas results, so we doubled the capacity of that component on the fly. - This exposed the next bottleneck in our platform in the form of an accumulation of the created results on a very small number of processing nodes. Normally the incoming measurement results are distributed over several storage nodes, so this strongly reduced the consumption rate of new data. - A third factor that contributed was the fact that, in attempt to curb growth of the Atlas data, we have migrated the Atlas data sets to a more efficient compression algorithm earlier in the year. This saved us some 40-50% of storage space for the Atlas data, at the expense of some compute power. Under normal circumstances, even at high loads, this compute power is abundantly available on the storage cluster. Under the specific circumstances of last Friday's events, it turned out that the change of the compression algorithm had increased processing time for some Hadoop system tasks by up to a factor of 8, which had a direct impact on the data consumption speed. Immediate actions taken: - Removed special privileges of the end-user in question - Added capacity to the Atlas consumer processes - Returned (temporarily) to less efficient compression on the Atlas data sets. Lessons learned and further planned action: - Granting special privileges for some of the Atlas users needs (even) more attention than it already receives. - We need to better communicate "best practices" to these power users so they can use their extra allowances responsibly. - Improved compression of Atlas data has decreased our storage demands but also decreased our processing capacity. This needs further investigation to find the optimum configuration. - Investigate possibilities to better spread incoming results over more worker nodes (reduce hotspots). - Investigate and quantify reasonable boundaries of scalability of the whole system, to guide the limits for granting credits to end users. Kind regards, Romeo Zwart From thinkofit at gmail.com Tue Sep 22 17:56:06 2015 From: thinkofit at gmail.com (Antonio Prado) Date: Tue, 22 Sep 2015 17:56:06 +0200 Subject: [atlas] Friday's events on RIPE Atlas In-Reply-To: <560174F2.10408@ripe.net> References: <560174F2.10408@ripe.net> Message-ID: <56017A16.4090505@gmail.com> On 9/22/15 5:34 PM, Romeo Zwart wrote: > - We need to better communicate "best practices" to these power users so > they can use their extra allowances responsibly. hi, who is a power user? maybe an anchor host or an atlas sponsor? thank you -- antonio From robert at ripe.net Wed Sep 23 08:54:46 2015 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 23 Sep 2015 08:54:46 +0200 Subject: [atlas] Friday's events on RIPE Atlas In-Reply-To: <56017A16.4090505@gmail.com> References: <560174F2.10408@ripe.net> <56017A16.4090505@gmail.com> Message-ID: <56024CB6.3090303@ripe.net> On 2015-09-22 17:56, Antonio Prado wrote: > On 9/22/15 5:34 PM, Romeo Zwart wrote: >> - We need to better communicate "best practices" to these power users so >> they can use their extra allowances responsibly. > > hi, > > who is a power user? > maybe an anchor host or an atlas sponsor? > > thank you > -- > antonio Hi, This was a Dutch researcher whose proposal (DNS anycast checks) was ultimately seen as useful, so we granted the higher than usual resource limits. Cheers, Robert From randy at psg.com Wed Sep 23 09:00:11 2015 From: randy at psg.com (Randy Bush) Date: Wed, 23 Sep 2015 13:00:11 +0600 Subject: [atlas] Friday's events on RIPE Atlas In-Reply-To: <560174F2.10408@ripe.net> References: <560174F2.10408@ripe.net> Message-ID: a great post mortem, thanks! my uneducated thoughts o disk is cheap; don't compress o occasionally, large scale measurements in narrow time windows will be useful randy From randy at psg.com Wed Sep 23 09:01:04 2015 From: randy at psg.com (Randy Bush) Date: Wed, 23 Sep 2015 13:01:04 +0600 Subject: [atlas] Friday's events on RIPE Atlas In-Reply-To: <56017A16.4090505@gmail.com> References: <560174F2.10408@ripe.net> <56017A16.4090505@gmail.com> Message-ID: > who is a power user? i don't think it is productive to go down this path randy From thinkofit at gmail.com Wed Sep 23 09:05:24 2015 From: thinkofit at gmail.com (Antonio Prado) Date: Wed, 23 Sep 2015 09:05:24 +0200 Subject: [atlas] Friday's events on RIPE Atlas In-Reply-To: References: <560174F2.10408@ripe.net> <56017A16.4090505@gmail.com> Message-ID: <56024F34.4070303@gmail.com> On 9/23/15 9:01 AM, Randy Bush wrote: >> who is a power user? > > i don't think it is productive to go down this path randy, you read my mind -- antonio From rm at romanrm.net Wed Sep 23 09:09:03 2015 From: rm at romanrm.net (Roman Mamedov) Date: Wed, 23 Sep 2015 12:09:03 +0500 Subject: [atlas] Friday's events on RIPE Atlas In-Reply-To: <56024F34.4070303@gmail.com> References: <560174F2.10408@ripe.net> <56017A16.4090505@gmail.com> <56024F34.4070303@gmail.com> Message-ID: <20150923120903.71863c25@natsu> On Wed, 23 Sep 2015 09:05:24 +0200 Antonio Prado wrote: > On 9/23/15 9:01 AM, Randy Bush wrote: > >> who is a power user? > > > > i don't think it is productive to go down this path > > randy, you read my mind You mean not productive trying to place the blame, or not productive to have shady anonymous "power users" being arbitrarily and behind-the-scenes granted the whole atlas infrastructure as their personal toy to play with? ^^ -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mark at santcroos.net Wed Sep 23 09:14:31 2015 From: mark at santcroos.net (Mark Santcroos) Date: Wed, 23 Sep 2015 09:14:31 +0200 Subject: [atlas] Friday's events on RIPE Atlas In-Reply-To: References: <560174F2.10408@ripe.net> Message-ID: On Wed, Sep 23, 2015 at 9:00 AM, Randy Bush wrote: > o disk is cheap; don't compress You need to update your cliches :-) Disk might be cheap, but I/O certainly isn't. From randy at psg.com Wed Sep 23 09:20:56 2015 From: randy at psg.com (Randy Bush) Date: Wed, 23 Sep 2015 13:20:56 +0600 Subject: [atlas] Friday's events on RIPE Atlas In-Reply-To: <20150923120903.71863c25@natsu> References: <560174F2.10408@ripe.net> <56017A16.4090505@gmail.com> <56024F34.4070303@gmail.com> <20150923120903.71863c25@natsu> Message-ID: >>>> who is a power user? >>> i don't think it is productive to go down this path >> randy, you read my mind > > You mean not productive trying to place the blame, or not productive > to have shady anonymous "power users" being arbitrarily and > behind-the-scenes granted the whole atlas infrastructure as their > personal toy to play with? ^^ QED From gert at space.net Wed Sep 23 10:22:09 2015 From: gert at space.net (Gert Doering) Date: Wed, 23 Sep 2015 10:22:09 +0200 Subject: [atlas] Friday's events on RIPE Atlas In-Reply-To: <20150923120903.71863c25@natsu> References: <560174F2.10408@ripe.net> <56017A16.4090505@gmail.com> <56024F34.4070303@gmail.com> <20150923120903.71863c25@natsu> Message-ID: <20150923082209.GK84167@Space.Net> Hi, On Wed, Sep 23, 2015 at 12:09:03PM +0500, Roman Mamedov wrote: > You mean not productive trying to place the blame, or not productive to have > shady anonymous "power users" being arbitrarily and behind-the-scenes granted > the whole atlas infrastructure as their personal toy to play with? ^^ I have always understood that if you need "more resources than your credits allowed", you could talk to the atlas team, explain your needs, and find a solution - so it seems this is what was done, as documented...? That it blew up the thing did obviously not work as planned, but the general option to have exceptions for tests that "really need all of the probes!" sounds useful to me. Document the process and criteria better? Maybe. Make a strict check-list of things, with 3 copies on paper required to circulate to all Atlas probe hosts? Certainly not. Balance between "things can be done" and "bureaucracy" must be found. gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From philip.homburg at ripe.net Wed Sep 23 10:57:38 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 23 Sep 2015 10:57:38 +0200 Subject: [atlas] Friday's events on RIPE Atlas In-Reply-To: <20150923082209.GK84167@Space.Net> References: <560174F2.10408@ripe.net> <56017A16.4090505@gmail.com> <56024F34.4070303@gmail.com> <20150923120903.71863c25@natsu> <20150923082209.GK84167@Space.Net> Message-ID: <56026982.60008@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015/09/23 10:22 , Gert Doering wrote: > I have always understood that if you need "more resources than > your credits allowed", you could talk to the atlas team, explain > your needs, and find a solution - so it seems this is what was > done, as documented...? > > That it blew up the thing did obviously not work as planned, but > the general option to have exceptions for tests that "really need > all of the probes!" sounds useful to me. > > Document the process and criteria better? Maybe. By nature, researchers want to do things that nobody else is doing. And in many cases they want it all. More data is better. Unfortunately, such an experiment may overload parts of Atlas in unexpected ways. I take it that documenting the process and criteria better is for the most part something internal to the Atlas team. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAmmCAAoJEPr6076EDopyYdAP+wZs9jonz8qsX6sT1kWbu2aa ZHQZNjcLODxcf+KNkV4uRuhJzjsu0+2+CqDxI/ZV5q7caOhxtQCYmY5zKN3k9FVg tzLZxle8Qy8MEJeHg68KX/Sv0r3Wu/dvnqVnfwy2mOknuV/Dy4kSNCahMkkzJbxN W7cw3ynXzllwBGK078BzGodruRivk8vSPa8OJQDuocD5iR/1JRih6Zfp9aMX0HcU jnDpBy44k6f8NN2Yr9kbQ+Kn5j3MACL3vSwMYrm3wToY/GNnwE1appJ+eh9Q3W0B keyDK2S6VLwA4ned3VEP6kxgVmNnJ9uLmKnd0n2cIcq/yXzPU+rHOmPtJs0B1DhS SEzp+NrpYjoDl9fxPuKrOgyc5uC2r9VnpvyPnBuUQmV2QdViG42C2+dqr3xEMLqM Se/mixm+0gzFlq9nbKw4gaW4cTrfgRpNAdOtUbcTjbZr+EuQUmzzDzbnOutyaDlF 35UmAG+WhjovdxAWQ/RE3CDxMYETHzTX6iZuu+2gls8M6LXJedbO/JYOSgYtibsC XBBy8+Kd6dNLeB4xnPiNb3jpz1L58eRuHSKye5oVIglfEKJ9h+4CTMNx2iOQPZCB TMApEwnHCX4W3Jmzy9MvoYMlafLt3alCh6yzTT0ISNdoKOmE5KTLGWLrRRLhWETc 549XiqyOkklaQszsj30S =jRS5 -----END PGP SIGNATURE----- From nick at inex.ie Wed Sep 23 11:00:39 2015 From: nick at inex.ie (Nick Hilliard) Date: Wed, 23 Sep 2015 10:00:39 +0100 Subject: [atlas] Friday's events on RIPE Atlas In-Reply-To: <20150923082209.GK84167@Space.Net> References: <560174F2.10408@ripe.net> <56017A16.4090505@gmail.com> <56024F34.4070303@gmail.com> <20150923120903.71863c25@natsu> <20150923082209.GK84167@Space.Net> Message-ID: <56026A37.9050007@inex.ie> On 23/09/2015 09:22, Gert Doering wrote: > Document the process and criteria better? Maybe. + learn lessons + move on + definitely don't stop doing interesting and exciting stuff just because there was a blip. Nick From colinj at mx5.org.uk Wed Sep 23 12:29:36 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Wed, 23 Sep 2015 11:29:36 +0100 Subject: [atlas] Friday's events on RIPE Atlas In-Reply-To: <560174F2.10408@ripe.net> References: <560174F2.10408@ripe.net> Message-ID: <7977782D-048C-40C7-8BA3-CD140D1295B7@mx5.org.uk> maybe compress the data info on the probes before it is sent and save to backend storage with the data already compress?d ? just a thought Colin From robert at ripe.net Wed Sep 23 12:37:56 2015 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 23 Sep 2015 12:37:56 +0200 Subject: [atlas] Friday's events on RIPE Atlas In-Reply-To: <7977782D-048C-40C7-8BA3-CD140D1295B7@mx5.org.uk> References: <560174F2.10408@ripe.net> <7977782D-048C-40C7-8BA3-CD140D1295B7@mx5.org.uk> Message-ID: <56028104.6020906@ripe.net> On 2015-09-23 12:29, Colin Johnston wrote: > maybe compress the data info on the probes before it is sent and save to backend storage with the data already compress?d ? > > just a thought > > Colin It may be interesting to know, although not at all surprising: compressing individual results achieves almost nothing (and has the drawback of having to unpack/repack while the result moves in the pipeline). Compressing small chunks, say dozens of related results (e.g. from the same measurement) achieves 40-50% saving (a lot depends on what kind of result it is), while compressing large blocks (multi-megabyte chunks) can achieve 90-95% in most cases. It makes sense to compress data once it's at rest, especially if it's not often accessed. Therefore our processing pipeline is constructed such that it applies compression once a large enough batch has been consumed. As Romeo explained, this part was stretched a lot on Friday. Cheers, Robert From colinj at mx5.org.uk Wed Sep 23 14:10:00 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Wed, 23 Sep 2015 13:10:00 +0100 Subject: [atlas] atlas probe usb power usage question In-Reply-To: <56028104.6020906@ripe.net> References: <560174F2.10408@ripe.net> <7977782D-048C-40C7-8BA3-CD140D1295B7@mx5.org.uk> <56028104.6020906@ripe.net> Message-ID: <2E7F5F6A-18CE-4528-9241-EB63EB96134B@mx5.org.uk> Hi all, quick techie question how much power is pulled via usb for the probev2 devices ? Colin From dquinn at ripe.net Wed Sep 23 14:30:21 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 23 Sep 2015 14:30:21 +0200 Subject: [atlas] RIPE Atlas Tools and Python versions Message-ID: <56029B5D.6010903@ripe.net> As some of you may already know, we?ve been working on a new command-line toolkit that will let you do nifty things like: * List measurement and probe metadata * Generate reports from measurement results * Stream measurement results It?s coming along quite nicely, but I?m running into just too many cases where support for Python 2.6 is (a) making my job harder, and (b) making my code uglier. Given that (a) means I spend more time fixing compatibility rather than adding features and (b) just makes me sad, I wanted to ask the community how important Python 2.6 is to you. So here?s the question: Of those of you who would find such a tool interesting/useful, how many of you *only* have access to a computer running Python 2.6? Such systems include CentOS distributions earlier than 7, and corresponding RedHat Enterprise systems. If you?re using Debian, or Ubuntu, you should already have 2.7 by default, and if you?re on Gentoo or Arch, you probably have both 2.7 and 3.5 already. I understand that Apple?s OSX is running 2.7 these days as well. If I don?t get a wave of messages about how very important 2.6 is to your collective health and wellbeing, I?m going to consider this a non-issue and drop support for 2.6. Thanks for your input everyone :-) ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From inigo at infornografia.net Wed Sep 23 14:37:53 2015 From: inigo at infornografia.net (=?UTF-8?Q?I=C3=B1igo_Ortiz_de_Urbina?=) Date: Wed, 23 Sep 2015 14:37:53 +0200 Subject: [atlas] RIPE Atlas Tools and Python versions In-Reply-To: <56029B5D.6010903@ripe.net> References: <56029B5D.6010903@ripe.net> Message-ID: Hi all On Wed, Sep 23, 2015 at 2:30 PM, Daniel Quinn wrote: > So here?s the question: > > Of those of you who would find such a tool interesting/useful, how many of > you only have access to a computer running Python 2.6? I for one am happy to drop support for 2.6, the systems where I'm likely to run the tool from will have >=2.7. And if they don't, I can always get it from RedHat/SCL. Cheers, -- "If you want to go fast, go alone. If you want to go far, go together." From Richard.Havern at geant.org Wed Sep 23 14:39:18 2015 From: Richard.Havern at geant.org (Rick Havern) Date: Wed, 23 Sep 2015 12:39:18 +0000 Subject: [atlas] RIPE Atlas Tools and Python versions In-Reply-To: <56029B5D.6010903@ripe.net> References: <56029B5D.6010903@ripe.net> Message-ID: Accord to python.org, Python 2.6 (final) was released on October 1st, 2008. It has served well, but is time to retire in favour of new features/better code. Rick From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Daniel Quinn Sent: 23 September 2015 13:30 To: RIPE Atlas People Subject: [atlas] RIPE Atlas Tools and Python versions As some of you may already know, we?ve been working on a new command-line toolkit that will let you do nifty things like: * List measurement and probe metadata * Generate reports from measurement results * Stream measurement results It?s coming along quite nicely, but I?m running into just too many cases where support for Python 2.6 is (a) making my job harder, and (b) making my code uglier. Given that (a) means I spend more time fixing compatibility rather than adding features and (b) just makes me sad, I wanted to ask the community how important Python 2.6 is to you. So here?s the question: Of those of you who would find such a tool interesting/useful, how many of you only have access to a computer running Python 2.6? Such systems include CentOS distributions earlier than 7, and corresponding RedHat Enterprise systems. If you?re using Debian, or Ubuntu, you should already have 2.7 by default, and if you?re on Gentoo or Arch, you probably have both 2.7 and 3.5 already. I understand that Apple?s OSX is running 2.7 these days as well. If I don?t get a wave of messages about how very important 2.6 is to your collective health and wellbeing, I?m going to consider this a non-issue and drop support for 2.6. Thanks for your input everyone :-) ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5928 bytes Desc: not available URL: From wilhelm at ripe.net Wed Sep 23 14:44:07 2015 From: wilhelm at ripe.net (Rene Wilhelm) Date: Wed, 23 Sep 2015 14:44:07 +0200 Subject: [atlas] RIPE Atlas Tools and Python versions In-Reply-To: <56029B5D.6010903@ripe.net> References: <56029B5D.6010903@ripe.net> Message-ID: <56029E97.9050402@ripe.net> On 9/23/15 2:30 PM, Daniel Quinn wrote: > [...] > > Of those of you who would find such a tool interesting/useful, how > many of you *only* have access to a computer running Python 2.6? > > Such systems include CentOS distributions earlier than 7, > which apparently includes RIPE NCC machines: $ uname -a Linux bastion1.hdp1.ripe.net 2.6.32-504.8.1.el6.x86_64 #1 SMP Wed Jan 28 21:11:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ whereis python python: /usr/bin/python2.6-config /usr/bin/python2.6 /usr/bin/python /usr/lib/python2.6 /usr/lib64/python2.6 /usr/include/python2.6 /opt/virtualenv/bin/python2.6 /opt/virtualenv/bin/python /usr/share/man/man1/python.1.gz $ /usr/bin/python -V Python 2.6.6 bastion1 is a number crunching front end to hadoop, a place where I run Atlas related jobs. Before dropping support for 2.6, can you guys ensure/coordinate 2.7 is available there? Thanks, -- Rene > and corresponding RedHat Enterprise systems. If you?re using Debian, > or Ubuntu, you should already have 2.7 by default, and if you?re on > Gentoo or Arch, you probably have both 2.7 and 3.5 already. I > understand that Apple?s OSX is running 2.7 these days as well. > > If I don?t get a wave of messages about how very important 2.6 is to > your collective health and wellbeing, I?m going to consider this a > non-issue and drop support for 2.6. > > Thanks for your input everyone :-) > > ? From wilhelm at ripe.net Wed Sep 23 14:49:35 2015 From: wilhelm at ripe.net (Rene Wilhelm) Date: Wed, 23 Sep 2015 14:49:35 +0200 Subject: [atlas] RIPE Atlas Tools and Python versions In-Reply-To: <56029E97.9050402@ripe.net> References: <56029B5D.6010903@ripe.net> <56029E97.9050402@ripe.net> Message-ID: <56029FDF.90109@ripe.net> oops, that was meant as an internal heads-up. Sorry spamming the list. -- Rene On 9/23/15 2:44 PM, Rene Wilhelm wrote: > > > On 9/23/15 2:30 PM, Daniel Quinn wrote: >> [...] >> >> Of those of you who would find such a tool interesting/useful, how >> many of you *only* have access to a computer running Python 2.6? >> >> Such systems include CentOS distributions earlier than 7, >> > > which apparently includes RIPE NCC machines: > > $ uname -a > Linux bastion1.hdp1.ripe.net 2.6.32-504.8.1.el6.x86_64 #1 SMP Wed > Jan 28 21:11:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > $ whereis python > python: /usr/bin/python2.6-config /usr/bin/python2.6 /usr/bin/python > /usr/lib/python2.6 /usr/lib64/python2.6 /usr/include/python2.6 > /opt/virtualenv/bin/python2.6 /opt/virtualenv/bin/python > /usr/share/man/man1/python.1.gz > $ /usr/bin/python -V > Python 2.6.6 > > bastion1 is a number crunching front end to hadoop, a place where I > run Atlas related jobs. > > Before dropping support for 2.6, can you guys ensure/coordinate 2.7 is > available there? > > Thanks, > > -- Rene > >> and corresponding RedHat Enterprise systems. If you?re using Debian, >> or Ubuntu, you should already have 2.7 by default, and if you?re on >> Gentoo or Arch, you probably have both 2.7 and 3.5 already. I >> understand that Apple?s OSX is running 2.7 these days as well. >> >> If I don?t get a wave of messages about how very important 2.6 is to >> your collective health and wellbeing, I?m going to consider this a >> non-issue and drop support for 2.6. >> >> Thanks for your input everyone :-) >> >> ? > > > From philip.homburg at ripe.net Wed Sep 23 14:50:35 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 23 Sep 2015 14:50:35 +0200 Subject: [atlas] atlas probe usb power usage question In-Reply-To: <2E7F5F6A-18CE-4528-9241-EB63EB96134B@mx5.org.uk> References: <560174F2.10408@ripe.net> <7977782D-048C-40C7-8BA3-CD140D1295B7@mx5.org.uk> <56028104.6020906@ripe.net> <2E7F5F6A-18CE-4528-9241-EB63EB96134B@mx5.org.uk> Message-ID: <5602A01B.6050103@ripe.net> On 2015/09/23 14:10 , Colin Johnston wrote: > Hi all, > quick techie question > how much power is pulled via usb for the probev2 devices ? Our highly specialized measuring equipment says... 0.22A :-) See attached picture. -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_20150923_143833-2.jpg Type: image/jpeg Size: 240835 bytes Desc: not available URL: From robert at ripe.net Wed Sep 23 14:58:38 2015 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 23 Sep 2015 14:58:38 +0200 Subject: [atlas] Downloading ad-hoc Atlas measurements as JSON In-Reply-To: <55FA9271.2060408@ripe.net> References: <55FA9271.2060408@ripe.net> Message-ID: <5602A1FE.8000300@ripe.net> On 2015-09-17 12:14, Vesna Manojlovic wrote: > Hi, > > sounds like a good idea, we'll add it to the roadmap! > > Thanks, > Vesna FYI: this has just been deployed. Cheers, Robert > On 17-sep.-15 12:11, Jonathan Brewer wrote: >> Hi All, >> >> One of my current frustrations is that when downloading ad-hoc Atlas >> measurements, the file name is always the same: >> "RIPE-Atlas-measurement.json". This is unfortunate. It would be great if >> the web server would by default call this measurement by its ID. >> >> Anyone else experiencing this problem? >> >> Regards, >> >> Jon From inigo at infornografia.net Wed Sep 23 15:04:05 2015 From: inigo at infornografia.net (=?UTF-8?Q?I=C3=B1igo_Ortiz_de_Urbina?=) Date: Wed, 23 Sep 2015 15:04:05 +0200 Subject: [atlas] Downloading ad-hoc Atlas measurements as JSON In-Reply-To: <5602A1FE.8000300@ripe.net> References: <55FA9271.2060408@ripe.net> <5602A1FE.8000300@ripe.net> Message-ID: On Wed, Sep 23, 2015 at 2:58 PM, Robert Kisteleki wrote: > FYI: this has just been deployed. RIPE-Atlas-measurement-{{ id }}.json. Works for me! :-) -- "If you want to go fast, go alone. If you want to go far, go together." From colinj at mx5.org.uk Wed Sep 23 15:05:41 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Wed, 23 Sep 2015 14:05:41 +0100 Subject: [atlas] Downloading ad-hoc Atlas measurements as JSON In-Reply-To: References: <55FA9271.2060408@ripe.net> <5602A1FE.8000300@ripe.net> Message-ID: > On 23 Sep 2015, at 14:04, I?igo Ortiz de Urbina wrote: > > On Wed, Sep 23, 2015 at 2:58 PM, Robert Kisteleki wrote: >> FYI: this has just been deployed. > > RIPE-Atlas-measurement-{{ id }}.json. > Works for me! :-) > a dated option like 20150923 would be nice as well Colin From BECHA at ripe.net Wed Sep 23 18:55:46 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 23 Sep 2015 18:55:46 +0200 Subject: [atlas] [] Downloading ad-hoc Atlas measurements as JSON In-Reply-To: References: <55FA9271.2060408@ripe.net> <5602A1FE.8000300@ripe.net> Message-ID: <5602D992.8060707@ripe.net> date & measurement ID make more sense... will you make that change? b On 23-sep.-15 15:05, Colin Johnston wrote: >> On 23 Sep 2015, at 14:04, I?igo Ortiz de Urbina wrote: >> >> On Wed, Sep 23, 2015 at 2:58 PM, Robert Kisteleki wrote: >>> FYI: this has just been deployed. >> >> RIPE-Atlas-measurement-{{ id }}.json. >> Works for me! :-) >> > > a dated option like 20150923 would be nice as well > > Colin > > > From jon.brewer at gmail.com Thu Sep 24 02:08:21 2015 From: jon.brewer at gmail.com (Jonathan Brewer) Date: Wed, 23 Sep 2015 13:08:21 -1100 Subject: [atlas] RIPE Atlas Tools and Python versions In-Reply-To: <56029B5D.6010903@ripe.net> References: <56029B5D.6010903@ripe.net> Message-ID: > So here?s the question: > > Of those of you who would find such a tool interesting/useful, how many of > you *only* have access to a computer running Python 2.6? > > All of my environments support 2.7 so I'm happy yo see 2.6 go away. > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Thu Sep 24 08:23:30 2015 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 24 Sep 2015 08:23:30 +0200 Subject: [atlas] Maintenance works today Message-ID: <560396E2.6080603@ripe.net> Dear All, We'll carry out maintenance work on the core RIPE Atlas infrastructure today, approximately between 10-11h Amsterdam time (8-9 UTC). This will also affect the API/UI, most likely resulting in failed API calls or web page loads. Excuses for the inconvenience. Regards, Robert Kisteleki From robert at ripe.net Thu Sep 24 08:28:44 2015 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 24 Sep 2015 08:28:44 +0200 Subject: [atlas] Downloading ad-hoc Atlas measurements as JSON In-Reply-To: References: <55FA9271.2060408@ripe.net> <5602A1FE.8000300@ripe.net> Message-ID: <5603981C.3040202@ripe.net> On 2015-09-23 15:05, Colin Johnston wrote: >> On 23 Sep 2015, at 14:04, I?igo Ortiz de Urbina wrote: >> >> On Wed, Sep 23, 2015 at 2:58 PM, Robert Kisteleki wrote: >>> FYI: this has just been deployed. >> >> RIPE-Atlas-measurement-{{ id }}.json. >> Works for me! :-) >> > > a dated option like 20150923 would be nice as well > > Colin Colin, can you explain what is your use case here? Such naming only really affects downloads via the web page / browser; when using the API one can easily choose a suitable download filename. We could add the end time as well, not just the start time, and we can choose unix timestamps vs. ISO times. All this is pretty simple, but I'd really like to avoid religious wars about how exactly to do this :) Regards, Robert From mgalante at ripe.net Thu Sep 24 15:17:13 2015 From: mgalante at ripe.net (Michela Galante) Date: Thu, 24 Sep 2015 15:17:13 +0200 Subject: [atlas] NIX.CZ (Czech Republic) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called cz-prg-as6881 and it is hosted by NIX.CZ in Prague, Czech Republic. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From wenqin.shao at telecom-paristech.fr Thu Sep 24 15:34:24 2015 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Thu, 24 Sep 2015 15:34:24 +0200 Subject: [atlas] Possible reasons behind a failed measurement Message-ID: Dear list, I recently launched a ping measurement that selects 50 anchors worldwide for a period of 24 hours, id 2439518. The measurement failed with no probe allocated to it. Do you have any clue on the possible reasons for that? One of my guesses is that anchors are highly demanded and non of them were available during the measurement window. I?d love to hear you thinkings on this matter. Many thanks for your attention. Best regards, Wenqin Shao ---- Ph.D candidate Telecom ParisTech -------------- next part -------------- An HTML attachment was scrubbed... URL: From BECHA at ripe.net Thu Sep 24 18:18:56 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 24 Sep 2015 18:18:56 +0200 Subject: [atlas] Latest three RIPE Labs articles about RIPE Atlas In-Reply-To: <560290BE.5050905@ripe.net> References: <560290BE.5050905@ripe.net> Message-ID: <56042270.6040802@ripe.net> Dear colleagues, there have been many new articles published on RIPE Labs: about RIPE Atlas features, using RIPE Atlas data for analysis, etc. Please find the info about the latest three in this email, and many more here: https://labs.ripe.net/atlas Regards, Vesna Looking at France-IX with RIPE Atlas and RIS, by Emile Aben Sep 24, 2015 10:09 AM This article describes our recent collaborations with France-IX on collecting data plane and control plane Internet data with RIPE Atlas and the RIPE NCC's Routing Information Service (RIS): https://labs.ripe.net/Members/emileaben/looking-at-france-ix-with-ripe-atlas-and-ris New RIPE Atlas Tool: LatencyMON, by Massimo Candela Sep 23, 2015 10:10 AM LatencyMON is a new RIPE Atlas web application that you can use to easily visualise and compare multiple latency trends collected by groups of RIPE Atlas probes. https://labs.ripe.net/Members/massimo_candela/new-ripe-atlas-tool-latencymon Checking your Internet Connectivity with RIPE Atlas Anchors, by St?phane Bortzmeyer Sep 14, 2015 05:05 PM If you monitor your external Internet connectivity, you may wonder which machine is the best to ping. Hesitate no more - you can use RIPE Atlas anchors as landmarks. https://labs.ripe.net/Members/stephane_bortzmeyer/checking-your-internet-connectivity-with-ripe-atlas-anchors From BECHA at ripe.net Fri Sep 25 12:50:07 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 25 Sep 2015 12:50:07 +0200 Subject: [atlas] New on RIPE Labs: Time Travel with RIPE Atlas In-Reply-To: <560505FF.1070909@ripe.net> References: <560505FF.1070909@ripe.net> Message-ID: <560526DF.1040600@ripe.net> Dear colleagues, Please find another new RIPE Atlas related article on RIPE Labs: RIPE Atlas users can now use a new feature on the maps to travel back in time: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-time-travel-is-here Kind regards, Vesna From BECHA at ripe.net Fri Sep 25 17:20:18 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 25 Sep 2015 17:20:18 +0200 Subject: [atlas] Save the date: RIPE Atlas Hackathon - 14-15 November - Bucharest Message-ID: <56056632.5040507@ripe.net> Dear all, It?s official: we will hold a new RIPE Atlas hackathon on the weekend before RIPE 71 in Bucharest. Join us, along with network operators and software developers from the Internet community, to work on RIPE Atlas tools. You'll have the chance to work alongside RIPE Atlas developers, meet others in your field, and exchange knowledge and experience. All source code developed during the hackathon will be publicly licensed and available on GitHub, and will be free for the entire community to use. Details: Date: 14-15 November 2015 Time: Saturday 09:00-19:00, Sunday 09:00-21:00 (including party) Location: JW Marriott Bucharest Grand Hotel, Bucharest, Romania We are looking for sponsors! Is your organisation interested in supporting our efforts? Please email me promptly and directly ? thank you! Finally, stay tuned - this is a pre-announcement. We will publish more details, along with the application form, early next week. I look forward to seeing you there! Regards, Vesna From astrikos at ripe.net Fri Sep 25 17:54:29 2015 From: astrikos at ripe.net (Andreas Strikos) Date: Fri, 25 Sep 2015 17:54:29 +0200 Subject: [atlas] Possible reasons behind a failed measurement In-Reply-To: References: Message-ID: <56056E35.50509@ripe.net> Hi, from what I see in our database you have specified as excluded tags "IPv6 Works" and " IPv6 Doesn't Work", which are mutually excluded :) Besides that, anchors are IPv6 capable so these leaves you with 0 anchros. I guess if you create a new measurement without specifying ""IPv6 Works" in the exclusion tags you will get the anchors you want. Regards, Andreas Strikos Ripe NCC On 24/09/15 15:34, Wenqin SHAO wrote: > Dear list, > > I recently launched a ping measurement that selects 50 anchors > worldwide for a period of 24 hours, id 2439518. The measurement > failed with no probe allocated to it. > Do you have any clue on the possible reasons for that? > One of my guesses is that anchors are highly demanded and non of them > were available during the measurement window. > I?d love to hear you thinkings on this matter. > > Many thanks for your attention. > > Best regards, > Wenqin Shao > > ---- > Ph.D candidate > Telecom ParisTech -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at anuragbhatia.com Sun Sep 27 22:50:18 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Mon, 28 Sep 2015 02:20:18 +0530 Subject: [atlas] Question about unstable power and probe Message-ID: Hello everyone! I have recently deployed a probe in a place where there's unstable power. Probe is rebooting like 4-5 times a day and unlikely power would be fixed in near future. I was wondering if it's safe for probe at all. Does anyone has experience with 4-5 reboots a day with probe? Will probe sustain it or better I just disconnect it and rather wait for power to become stable? Curious to hear your experiences. Thanks. -- Anurag Bhatia anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Sun Sep 27 23:11:18 2015 From: nick at inex.ie (Nick Hilliard) Date: Sun, 27 Sep 2015 22:11:18 +0100 Subject: [atlas] Question about unstable power and probe In-Reply-To: References: Message-ID: <56085B76.6070406@inex.ie> On 27/09/2015 21:50, Anurag Bhatia wrote: > I have recently deployed a probe in a place where there's unstable power. > Probe is rebooting like 4-5 times a day and unlikely power would be fixed > in near future. why not attach a UPS? www.amazon.com/dp/B00KEGYXRQ Nick From remaker at gmail.com Sun Sep 27 23:03:39 2015 From: remaker at gmail.com (Phillip Remaker) Date: Sun, 27 Sep 2015 14:03:39 -0700 Subject: [atlas] Question about unstable power and probe In-Reply-To: References: Message-ID: Maybe you should attach the power to a cheap USB battery pack and leave that permanently recharging? Some cannot simultaneously charge and discharge. Some can. The "USB UPS" is the tool you want here. Example: http://raspi.tv/2013/testing-rs-5200-mah-usb-lithium-battery-pack-as-a-ups I think the bigger problem would be "fluttering" power that might cause the probe to hang and require a manual hard power cycle. But if the power interruptions are short, an in-line battery should help. On Sun, Sep 27, 2015 at 1:50 PM, Anurag Bhatia wrote: > Hello everyone! > > > I have recently deployed a probe in a place where there's unstable power. > Probe is rebooting like 4-5 times a day and unlikely power would be fixed > in near future. > > > I was wondering if it's safe for probe at all. Does anyone has experience > with 4-5 reboots a day with probe? Will probe sustain it or better I just > disconnect it and rather wait for power to become stable? > > > > Curious to hear your experiences. > > > > Thanks. > > -- > > > Anurag Bhatia > anuragbhatia.com > > > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinj at mx5.org.uk Mon Sep 28 09:29:00 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Mon, 28 Sep 2015 08:29:00 +0100 Subject: [atlas] Fwd: Byte Night Manchester - Action for Children - donation help needed please :) References: <402e9cc097014acfbd9f7510d78e7994@rew09926dag10a.domain1.systemhost.net> Message-ID: <558A1E77-2CC2-4142-9B56-EC092A5CD992@mx5.org.uk> Hopefully IT folks will donate to this great cause, hopefully folks will allow this posting :) > Begin forwarded message: > > From: > Date: 28 September 2015 at 08:12:03 BST > To: > Subject: FW: Byte Night Manchester - Action for Children - donation help needed please :) > > > > > > Dear all, > As my regular yearly charity participation event please support below > Byte Night Manchester - BT Manchester folks ? Colin team of one. > > On Friday night next, 2nd Oct 2015 from 7pm to 6am next morning, I (Colin Johnston) am participating in > Action for Children Byte Night Manchester. > As we have been asked to dress up for nice social media pictures I decided that being dressed as a Sylvester Cat > would be good fun. > I have managed to get http://celebrationpartyshoponline.co.uk/stores to give me a discount on the costume hire as well. > The Byte Night for Manchester is being held at Granada Studios in Manchester on the street of Coronation Street. > > We(Byte Night participants) are sleeping on the street in sleeping bags and foil survival bag. > > Please donate to this great cause, either by donation bucket in BT Bolton AMTE (Sylvester will be in Bolton on Thursday/Friday) or > BT Dial House Manchester (Sylvester will make a visit on Friday), > or via internet https://www.justgiving.com/bt-bt-manchester-folks/4w350m3/donate#MessageAndAmount > > Please email me colin.johnstone at bt.com if donation made so I can keep track of donators list. > I want to transfer the total raised to Action for Children by middle of Oct so please give money via above either this week coming or next. > I will email folks with acknowledgement of final donation amount once received, would be great to get 500 pounds ++.. > > Pictures will be sent after the event for BT Today and all on this email to listJ > > Please give generously if you can afford it, pay day on Wednesday J > > Please distribute widely if you think others not mentioned would be willing to donate JJ > > Yours > > Colin Johnston -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: images.jpg Type: image/jpeg Size: 6006 bytes Desc: not available URL: From wenqin.shao at telecom-paristech.fr Mon Sep 28 12:05:39 2015 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Mon, 28 Sep 2015 12:05:39 +0200 Subject: [atlas] Possible reasons behind a failed measurement In-Reply-To: <56056E35.50509@ripe.net> References: <56056E35.50509@ripe.net> Message-ID: <2D8B0FF1-6527-4DC4-979F-7722A3A10270@telecom-paristech.fr> Hi Andreas, Thank you very much for looking into my case. It was exactly what you've explained. I launched new measurements without ?IPv6 doesn?t work? tag. And now everything is just right. Again many thanks for your timely help and accurate indications. Best regards, Wenqin > On 25 Sep 2015, at 17:54, Andreas Strikos wrote: > > Hi, > > from what I see in our database you have specified as excluded tags "IPv6 Works" and " IPv6 Doesn't Work", which are mutually excluded :) > Besides that, anchors are IPv6 capable so these leaves you with 0 anchros. > I guess if you create a new measurement without specifying ""IPv6 Works" in the exclusion tags you will get the anchors you want. > > Regards, > Andreas Strikos > Ripe NCC > > > On 24/09/15 15:34, Wenqin SHAO wrote: >> Dear list, >> >> I recently launched a ping measurement that selects 50 anchors worldwide for a period of 24 hours, id 2439518. The measurement failed with no probe allocated to it. >> Do you have any clue on the possible reasons for that? >> One of my guesses is that anchors are highly demanded and non of them were available during the measurement window. >> I?d love to hear you thinkings on this matter. >> >> Many thanks for your attention. >> >> Best regards, >> Wenqin Shao >> >> ---- >> Ph.D candidate >> Telecom ParisTech > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Mon Sep 28 12:53:14 2015 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 28 Sep 2015 12:53:14 +0200 Subject: [atlas] Possible reasons behind a failed measurement In-Reply-To: <2D8B0FF1-6527-4DC4-979F-7722A3A10270@telecom-paristech.fr> References: <56056E35.50509@ripe.net> <2D8B0FF1-6527-4DC4-979F-7722A3A10270@telecom-paristech.fr> Message-ID: <56091C1A.3050008@ripe.net> On 2015-09-28 12:05, Wenqin SHAO wrote: > Hi Andreas, > > Thank you very much for looking into my case. > It was exactly what you've explained. > I launched new measurements without ?IPv6 doesn?t work? tag. And now > everything is just right. > Again many thanks for your timely help and accurate indications. > > Best regards, > Wenqin Hi, As a follow-up: we made a note to ourselves to expose more of these details in the UI. Regards, Robert From mgalante at ripe.net Mon Sep 28 14:06:12 2015 From: mgalante at ripe.net (Michela Galante) Date: Mon, 28 Sep 2015 14:06:12 +0200 Subject: [atlas] Liquid Web (Haarlem, Netherlands) has joined RIPE Atlas Anchors Message-ID: <133CBBD7-C94F-4DC5-BB94-5E2D9200720E@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called nl-haa-as201682 and it is hosted by Liquid Web in Haarlem, Netherlands. Congratulations to Liquid Web for their third anchor online! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From mgalante at ripe.net Tue Sep 29 13:51:32 2015 From: mgalante at ripe.net (Michela Galante) Date: Tue, 29 Sep 2015 13:51:32 +0200 Subject: [atlas] Leaseweb Network B.V. (Frankfurt, Germany) has joined RIPE Atlas Anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called de-fra-as28753 and it is hosted by Leaseweb Network B.V. in Frankfurt, Germany. Congratulations to Leaseweb Network for their second anchor online! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From BECHA at ripe.net Tue Sep 29 16:54:26 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 29 Sep 2015 16:54:26 +0200 Subject: [atlas] Join RIPE Atlas Hackathon - 14-15 November - Bucharest In-Reply-To: References: Message-ID: <560AA622.5050903@ripe.net> Calling all software developers, designers and network operators! The next RIPE Atlas hackathon takes place 14-15 November in Bucharest, right before RIPE 71. We're looking for creative thinkers to help us find new ways to use RIPE Atlas data to monitor networks and troubleshoot issues as well as ways to improve the existing toolset. Is this you? Then we want to hear from you! ----------------------- How to Apply ----------------------- The application form is online at: https://atlas.ripe.net/hackathon/tools-2015/#!application-form *The deadline to apply is Tuesday, 6 October* Successful applicants will: - Work alongside RIPE Atlas engineers - Get to know others in your field - Contribute to the shared code - Exchange knowledge and experience All source code developed during the hackathon will be publicly licensed and available on GitHub, and will be free for the entire community to use. ---------------------- Hackathon details --------------------- Date: 14-15 November 2015 Time: Saturday 09:00-19:00, Sunday 09:00-21:00 (including party) Location: JW Marriott Bucharest Grand Hotel, Bucharest, Romania Applicants will hear back from the jury on 12 October so that travel arrangements can be made on time. Find out more on RIPE Labs: https://labs.ripe.net/Members/becha/join-the-ripe-atlas-tools-hackathon -------------------- Call for Sponsors ------------------- We are still looking for sponsors! Is your organisation interested in supporting our efforts? Please email me promptly and directly ? thank you! I look forward to seeing you there! Regards, Vesna