From vobelic at gbit6.net Sun May 1 01:03:43 2016 From: vobelic at gbit6.net (Vladimir-M. Obelic) Date: Sun, 01 May 2016 01:03:43 +0200 Subject: [atlas] Atlas probe down and probe replacement In-Reply-To: Message-ID: Ah so it reformats it automatically... Great, boot up without USB and inserting it later on fixed the issue. Probe works and is now connected to the grid :) Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From hostmaster at ionescu.de Sun May 1 09:56:16 2016 From: hostmaster at ionescu.de (Michael Ionescu) Date: Sun, 01 May 2016 09:56:16 +0200 Subject: [atlas] An article/FAQ entry about probe troubleshooting In-Reply-To: <56A75011.1030307@ripe.net> Message-ID: Hi, > > I think though that there should still be more debugging info for connections. > > > However, we're working on a feature to give probe hosts more guidance about > > what's going on (and especially what's going wrong) with their probe (*), > > and here we will make it clear if the USB replacement is in order. In the interim, the status feature has been launched, but it doesn't help when the probe does not connect to the atlas server. > Besides this, I'm sure we'll happily endorse any kind of community-written > troubleshooting guides :) For want of a better place I've started a troubleshooting guide on my wikipedia sandbox and would invite the community to help bring it to fruition. Your contributions are appreciated! https://en.wikipedia.org/wiki/User:Mhi/sandbox/Troubleshooting_RIPE-Atlas_Probes Regards, Michael Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From hank at efes.iucc.ac.il Sun May 1 15:43:26 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 1 May 2016 16:43:26 +0300 Subject: [atlas] An article/FAQ entry about probe troubleshooting In-Reply-To: References: Message-ID: On 01/05/2016 10:56, Michael Ionescu wrote: > Hi, > >>> I think though that there should still be more debugging info for connections. >>> However, we're working on a feature to give probe hosts more guidance about >>> what's going on (and especially what's going wrong) with their probe (*), >>> and here we will make it clear if the USB replacement is in order. > In the interim, the status feature has been launched, but it doesn't help when the probe does not connect to the atlas server. > >> Besides this, I'm sure we'll happily endorse any kind of community-written >> troubleshooting guides :) > For want of a better place I've started a troubleshooting guide on my wikipedia sandbox and would invite the community to help bring it to fruition. Your contributions are appreciated! > https://en.wikipedia.org/wiki/User:Mhi/sandbox/Troubleshooting_RIPE-Atlas_Probes Very nice! Thanks, Hank > > Regards, > Michael > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From ripecontact at markyate.net Mon May 2 00:40:51 2016 From: ripecontact at markyate.net (Alison Wheeler) Date: Mon, 02 May 2016 00:40:51 +0200 Subject: [atlas] An article/FAQ entry about probe troubleshooting In-Reply-To: <56A63D52.4030902@cesnet.cz> Message-ID: Useful idea (and made a small edit). Although some troubleshooting can be carried out via the probe's web datapage the only other option still appears to be the physical 'remove card, reformat, replace' one. I've noted in the past that the probe can be showing itself as 'down' when the link is demonstrably up (because I'm using it!) which puzzles me, and again begs the question of whether the probe can be 'nudged' or rebooted via a local IP call of some sort (cf. wakeup packet) if it appears to have a problem but the probe is remote from the owner. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From contact.anthoo at gmail.com Mon May 2 16:45:23 2016 From: contact.anthoo at gmail.com (Anthony) Date: Mon, 2 May 2016 16:45:23 +0200 Subject: [atlas] DNS entry In-Reply-To: References: Message-ID: <57276803.6020605@gmail.com> Hello, In the edition of general probe of my information, I see that there are marked "DNS" with several choices: OFF, SINPLE or obfuscated. I would have wanted to know what it matched? And what he had to choose. Thank you in advance. From contact.anthoo at gmail.com Mon May 2 17:03:23 2016 From: contact.anthoo at gmail.com (Anthony) Date: Mon, 2 May 2016 17:03:23 +0200 Subject: [atlas] DNS entry In-Reply-To: References: <57276803.6020605@gmail.com> Message-ID: <57276C3B.90709@gmail.com> Okay thank you for the answer. Should he therefore leave the "OFF"? Le 02/05/2016 17:01, Micha Bailey a ?crit : > Essentially, this is a dynamic DNS service bound to the probe. If you > choose "simple" the hostname will be something like > p#####.probes.atlas.ripe.net , with the > probe number. If you choose "obfuscated", the hostname will be > something else. I don't know exactly what it looks like, but it's > something less identifying. > > On Monday, May 2, 2016, Anthony > wrote: > > Hello, > > In the edition of general probe of my information, I see that > there are marked "DNS" with several choices: OFF, SINPLE or > obfuscated. > > I would have wanted to know what it matched? And what he had to > choose. > > Thank you in advance. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripecontact at markyate.net Thu May 5 15:11:43 2016 From: ripecontact at markyate.net (Alison Wheeler) Date: Thu, 05 May 2016 15:11:43 +0200 Subject: [atlas] SixXS issues Message-ID: I received my second probe* yesterday (different ASNs) and it is connects via SixXS for IPv6 as the ISP isn't supplying native v6 (despite repeatedly asking when they will catch up on something around for twenty years!). It booted fine and the appear no issues with the IPv4 connectivity but the v6 is going up and down every few minutes (for around the same period.) Not finding anything relevant after searching the forum (nor on google) I'm trying to discover why this might be. My other machines are not experiencing any difficulty with v6 connectivity and the probe is connected to the same 16-port switch as everything else. Suggestions of what to investigate next very welcome! * https://atlas.ripe.net/probes/28800/ Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From laurar at princeton.edu Thu May 5 09:43:22 2016 From: laurar at princeton.edu (Laura M. Roberts) Date: Thu, 5 May 2016 07:43:22 +0000 Subject: [atlas] UDP Traceroute port? Message-ID: <24AF79C9-32FB-4D54-8C14-3B7825BB86ED@princeton.edu> Hello, What port is used when a UDP traceroute is performed, please? Thank you, Laura From cs at fnx.li Fri May 6 12:02:16 2016 From: cs at fnx.li (=?UTF-8?Q?Christian_Schr=c3=b6tter?=) Date: Fri, 6 May 2016 12:02:16 +0200 Subject: [atlas] UDP Traceroute port? In-Reply-To: <24AF79C9-32FB-4D54-8C14-3B7825BB86ED@princeton.edu> References: <24AF79C9-32FB-4D54-8C14-3B7825BB86ED@princeton.edu> Message-ID: <572C6BA8.5040102@fnx.li> Hello Laura! > What port is used when a UDP traceroute is performed, please? Wikipedia[1] says 33434-33534, my own firewall rules 33434-33655. -- With kind regards, Christian Schr?tter [1] https://en.wikipedia.org/wiki/Traceroute From laurar at princeton.edu Fri May 6 15:22:54 2016 From: laurar at princeton.edu (Laura M. Roberts) Date: Fri, 6 May 2016 13:22:54 +0000 Subject: [atlas] UDP Traceroute port? In-Reply-To: <572C6BA8.5040102@fnx.li> References: <24AF79C9-32FB-4D54-8C14-3B7825BB86ED@princeton.edu>, <572C6BA8.5040102@fnx.li> Message-ID: <4604AFF5-98A7-4FA9-B00A-0BA2B822B1ED@exchange.Princeton.EDU> Oh, gosh, I didn't realize the answer would have been on Wikipedia. Thank you very much for your answer, Christian!! Kind regards, Laura > On May 6, 2016, at 6:02 AM, Christian Schr?tter wrote: > > Hello Laura! > >> What port is used when a UDP traceroute is performed, please? > Wikipedia[1] says 33434-33534, my own firewall rules 33434-33655. > > -- > With kind regards, > Christian Schr?tter > > [1] https://en.wikipedia.org/wiki/Traceroute > From rolf.sommerhalder at alumni.ethz.ch Sun May 8 13:58:38 2016 From: rolf.sommerhalder at alumni.ethz.ch (Rolf Sommerhalder) Date: Sun, 8 May 2016 13:58:38 +0200 Subject: [atlas] SixXS issues In-Reply-To: References: Message-ID: On Thu, May 5, 2016 at 3:11 PM, Alison Wheeler wrote: > ... but the v6 is going up and down every few minutes (for around the same period.) For many months, one of my Atlas probe (v1/v2, firmware 4730) has been running quite nicely through a SixXS IPv6 tunnel. But starting two or three months ago, this probe goes up and down every two to four minutes. As soon as I block all IPv6 connections to/from the probe, it is connectivity over IPv4 only (behind a NAT firewall) is stable and the probe stays up. In another location, a second Atlas probe (v3, firmware 4730) runs stable with dual-stack through a IPv6 tunnel from Hurricane Electric, and with a very similar rule-set on the firewall (pfSense/FreeBSD). Currently, I am looking potential causes: a) My firewall (pf on OpenBSD) rules over-block incoming ICMP6 requests, if Atlas control hosts should now check if the probe has two-way IPv6 connectivity. b) MTU size mismatch somewhere with my SixXS tunnel setup. c) Static vs. dynamic configuration of the probes for IPv6. I will report any progress/findings. Suggestions welcome, thanks! From mcandela at ripe.net Mon May 9 17:25:46 2016 From: mcandela at ripe.net (Massimo Candela) Date: Mon, 9 May 2016 17:25:46 +0200 Subject: [atlas] LatencyMON Widget Y axis in milliseconds In-Reply-To: <570E0207.1090508@rqc.ru> References: <570E0207.1090508@rqc.ru> Message-ID: <779A20A4-8F75-497C-A44C-4F57B58C07B9@ripe.net> Hi Marat, > On 13 Apr 2016, at 10:23, Marat Khalili wrote: > > I'm using LatencyMON widget to monitor my network performance. It's very convenient. Unfortunately, it always loads with latency shown in %% (of what?), not in milliseconds, so I have to make one extra click in order to view actual milliseconds. Is there some hidden switch that would make milliseconds the default? Shouldn't it be initially default in the first place? Thanks for your comment, I will try to answer and give my opinion. Here you can find the documentation: https://atlas.ripe.net/docs/tools-latencymon/ According to it: "The relative representation shows, in percentages, how the values behave compared to the baseline, which is the minimum latency collected in the time range for the specific graph. Note that outliers have been removed. For example, if the latencies collected oscillate between 30 and 90 ms, the y-axis will have a range between 0 and 200%, as 30 ms will be considered the baseline and 90 ms represents an increase of 200% over 30 ms.? The relative representation allows the user to focus on change in the RTT over time and geographic space, instead of a pure comparison among milliseconds of the various probes. Following the user requests and according also to our internal use, this is the most common use case, especially in case of outage analysis. For example if you have a probe in Canada and one in Italy and the target used in the measurement is in Germany, you would expect to have some ms more from the one in Canada: this information it?s just going to pollute the graphs. Probably if something happens on the network you would like to know which probes were affected and how. So what is the difference in RTT compared to what is considered ?normal? from that source. You can anyway force to open the measurement in ms (the same goes for all the other parameters) if you embed the widget in your html page/monitor/dashboard. Sorry for the delay of the answer, for more information feel free to contact me personally. Ciao, Massimo > > -- > > With Best Regards, > Marat Khalili -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From Clinton.Work at telus.com Mon May 9 23:06:11 2016 From: Clinton.Work at telus.com (Clinton Work) Date: Mon, 9 May 2016 15:06:11 -0600 Subject: [atlas] ping measurements and high lts Message-ID: When looking at the ping measurement json results I found some probes are reporting a very high lts (last time synchronized). Is it normal for very high lts values to be reported? These two anchors seem chronic: Probe 6161, max lts 65807 Probe 6132, max lts 23905 ================================= Clinton Work From mkh at rqc.ru Tue May 10 09:20:17 2016 From: mkh at rqc.ru (Marat Khalili) Date: Tue, 10 May 2016 10:20:17 +0300 Subject: [atlas] LatencyMON Widget Y axis in milliseconds In-Reply-To: <779A20A4-8F75-497C-A44C-4F57B58C07B9@ripe.net> References: <570E0207.1090508@rqc.ru> <779A20A4-8F75-497C-A44C-4F57B58C07B9@ripe.net> Message-ID: <57318BB1.1040001@rqc.ru> Hello Massimo, Thank you very much for your reply. > You can anyway force to open the measurement in ms (the same goes for > all the other parameters) if you embed the widget in your html > page/monitor/dashboard. That's exactly what I'm doing: I've created a web-page on my internal web-server that contains the widget. However, I still cannot find neither parameter nor API that would allow me to select milliseconds. I've read through both documentation page you pointed and poked JavaScript object returned by initLatencymon, but still don't see it. That said, reference point in milliseconds appeared on charts recently, that somewhat makes it less of a problem for me. > The relative representation allows the user to focus on change in the > RTT over time and geographic space, instead of a pure comparison among > milliseconds of the various probes. > Following the user requests and according also to our internal use, > this is the most common use case, especially in case of outage analysis. My (mis)use case is different: I'm trying to monitor one particular link that's important for me, using a single probe and multiple nearby destinations. In this case absolute values matter: relative charts may look absolutely normal while absolute values are elevated from 1..2 to 10+ milliseconds because to link overload which is not good. -- With Best Regards, Marat Khalili On 09/05/16 18:25, Massimo Candela wrote: > Hi Marat, > >> On 13 Apr 2016, at 10:23, Marat Khalili > > wrote: >> >> I'm using LatencyMON >> widget to monitor my network performance. It's very convenient. >> Unfortunately, it always loads with latency shown in %% (of what?), >> not in milliseconds, so I have to make one extra click in order to >> view actual milliseconds. Is there some hidden switch that would make >> milliseconds the default? Shouldn't it be initially default in the >> first place? > > > Thanks for your comment, I will try to answer and give my opinion. > > Here you can find the documentation: > https://atlas.ripe.net/docs/tools-latencymon/ > According to it: "The relative representation shows, in percentages, > how the values behave compared to the baseline, which is the minimum > latency collected in the time range for the specific graph. Note that > outliers have been removed. > For example, if the latencies collected oscillate between 30 and 90 > ms, the y-axis will have a range between 0 and 200%, as 30 ms will be > considered the baseline and 90 ms represents an increase of 200% over > 30 ms.? > > The relative representation allows the user to focus on change in the > RTT over time and geographic space, instead of a pure comparison among > milliseconds of the various probes. > Following the user requests and according also to our internal use, > this is the most common use case, especially in case of outage analysis. > For example if you have a probe in Canada and one in Italy and the > target used in the measurement is in Germany, you would expect to have > some ms more from the one in Canada: this information it?s just going > to pollute the graphs. > Probably if something happens on the network you would like to know > which probes were affected and how. So what is the difference in RTT > compared to what is considered ?normal? from that source. > > You can anyway force to open the measurement in ms (the same goes for > all the other parameters) if you embed the widget in your html > page/monitor/dashboard. > > Sorry for the delay of the answer, for more information feel free to > contact me personally. > > Ciao, > Massimo > > > >> >> -- >> >> With Best Regards, >> Marat Khalili > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Tue May 10 12:06:07 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 10 May 2016 12:06:07 +0200 Subject: [atlas] ping measurements and high lts In-Reply-To: References: Message-ID: <5731B28F.1050603@ripe.net> Hi, On 2016/05/09 23:06 , Clinton Work wrote: > When looking at the ping measurement json results I found some probes are reporting a very high lts (last time synchronized). Is it normal for very high lts values to be reported? > > These two anchors seem chronic: > Probe 6161, max lts 65807 > Probe 6132, max lts 23905 I liked into this. It is caused by two separate issues. 6161 had a clock that was way off. This is caused by the rather old ntpd on CentOS. We restarted ntpd. We will look into better monitoring for this. For 6132 the problem is that the round trip latency to the RIPE NCC is high enough that the lts value doesn't get reset. (The lts value gets reset whenever the probe code can verify that the local clock is in sync with the one of the controller. With a high enough latency you just don't know.) Philip From mcandela at ripe.net Tue May 10 12:31:10 2016 From: mcandela at ripe.net (Massimo Candela) Date: Tue, 10 May 2016 12:31:10 +0200 Subject: [atlas] LatencyMON Widget Y axis in milliseconds In-Reply-To: <57318BB1.1040001@rqc.ru> References: <570E0207.1090508@rqc.ru> <779A20A4-8F75-497C-A44C-4F57B58C07B9@ripe.net> <57318BB1.1040001@rqc.ru> Message-ID: <11DE2A09-66F9-4FAE-9505-794A3A4C4BCC@ripe.net> Hi Marat, > On 10 May 2016, at 09:20, Marat Khalili wrote: > > Hello Massimo, > > Thank you very much for your reply. >> You can anyway force to open the measurement in ms (the same goes for all the other parameters) if you embed the widget in your html page/monitor/dashboard. > That's exactly what I'm doing: I've created a web-page on my internal web-server that contains the widget. However, I still cannot find neither parameter nor API that would allow me to select milliseconds. I've read through both documentation page you pointed and poked JavaScript object returned by initLatencymon, but still don't see it. Option 1: Set the parameter in the embed code (more info at the end of the documentation page) dataFilter [string] The data filter name to be used (i.e. natural or relative). So practically you need something like: { dataFilter: "natural", measurements:[MSM_ID1, MSM_ID2] } in your query options map (third parameter of initLatencymon). In this way the widget will load the measurement with all the default parameters you set. If you want to change it at execution time: - open your browser console; - latencymon.shell().setDataFilter(?natural?), where latencymon is the object returned by initLatencymon() Be careful: don?t simply reload the page, remove all the parameters in the permalink. The permalink has priority so if in the permalink you have another filter, this will overwrite the one specified in the embed code. > > That said, reference point in milliseconds appeared on charts recently, that somewhat makes it less of a problem for me. ;) But anyway try the solution before, it will fit better your case. > >> The relative representation allows the user to focus on change in the RTT over time and geographic space, instead of a pure comparison among milliseconds of the various probes. >> Following the user requests and according also to our internal use, this is the most common use case, especially in case of outage analysis. > My (mis)use case is different: I'm trying to monitor one particular link that's important for me, using a single probe and multiple nearby destinations. In this case absolute values matter: relative charts may look absolutely normal while absolute values are elevated from 1..2 to 10+ milliseconds because to link overload which is not good. > Let me know if everything is fine! Ciao, Massimo > -- > > With Best Regards, > Marat Khalili > > On 09/05/16 18:25, Massimo Candela wrote: >> Hi Marat, >> >>> On 13 Apr 2016, at 10:23, Marat Khalili < mkh at rqc.ru > wrote: >>> >>> I'm using LatencyMON widget to monitor my network performance. It's very convenient. Unfortunately, it always loads with latency shown in %% (of what?), not in milliseconds, so I have to make one extra click in order to view actual milliseconds. Is there some hidden switch that would make milliseconds the default? Shouldn't it be initially default in the first place? >> >> >> Thanks for your comment, I will try to answer and give my opinion. >> >> Here you can find the documentation: https://atlas.ripe.net/docs/tools-latencymon/ >> According to it: "The relative representation shows, in percentages, how the values behave compared to the baseline, which is the minimum latency collected in the time range for the specific graph. Note that outliers have been removed. >> For example, if the latencies collected oscillate between 30 and 90 ms, the y-axis will have a range between 0 and 200%, as 30 ms will be considered the baseline and 90 ms represents an increase of 200% over 30 ms.? >> >> The relative representation allows the user to focus on change in the RTT over time and geographic space, instead of a pure comparison among milliseconds of the various probes. >> Following the user requests and according also to our internal use, this is the most common use case, especially in case of outage analysis. >> For example if you have a probe in Canada and one in Italy and the target used in the measurement is in Germany, you would expect to have some ms more from the one in Canada: this information it?s just going to pollute the graphs. >> Probably if something happens on the network you would like to know which probes were affected and how. So what is the difference in RTT compared to what is considered ?normal? from that source. >> >> You can anyway force to open the measurement in ms (the same goes for all the other parameters) if you embed the widget in your html page/monitor/dashboard. >> >> Sorry for the delay of the answer, for more information feel free to contact me personally. >> >> Ciao, >> Massimo >> >> >> >>> >>> -- >>> >>> With Best Regards, >>> Marat Khalili >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From mkh at rqc.ru Tue May 10 13:59:00 2016 From: mkh at rqc.ru (Marat Khalili) Date: Tue, 10 May 2016 14:59:00 +0300 Subject: [atlas] LatencyMON Widget Y axis in milliseconds In-Reply-To: <11DE2A09-66F9-4FAE-9505-794A3A4C4BCC@ripe.net> References: <570E0207.1090508@rqc.ru> <779A20A4-8F75-497C-A44C-4F57B58C07B9@ripe.net> <57318BB1.1040001@rqc.ru> <11DE2A09-66F9-4FAE-9505-794A3A4C4BCC@ripe.net> Message-ID: <5731CD04.7050902@rqc.ru> It works! Did not realize it is called this way, thank you! -- With Best Regards, Marat Khalili On 10/05/16 13:31, Massimo Candela wrote: > Hi Marat, > >> On 10 May 2016, at 09:20, Marat Khalili > > wrote: >> >> Hello Massimo, >> >> Thank you very much for your reply. >>> You can anyway force to open the measurement in ms (the same goes >>> for all the other parameters) if you embed the widget in your html >>> page/monitor/dashboard. >> That's exactly what I'm doing: I've created a web-page on my internal >> web-server that contains the widget. However, I still cannot find >> neither parameter nor API that would allow me to select milliseconds. >> I've read through both documentation page you pointed and poked >> JavaScript object returned by initLatencymon, but still don't see it. > > Option 1: Set the parameter in the embed code (more info at the end of > the documentation page) > dataFilter [string] The data filter name to be used (i.e. natural or > relative). > > So practically you need something like: > { > dataFilter: "natural", > measurements:[MSM_ID1, MSM_ID2] > } > > in your query options map (third parameter of initLatencymon). > In this way the widget will load the measurement with all the default > parameters you set. > > > If you want to change it at execution time: > - open your browser console; > - latencymon.shell().setDataFilter(?natural?), where latencymon is the > object returned by initLatencymon() > > > Be careful: don?t simply reload the page, remove all the parameters in > the permalink. The permalink has priority so if in the permalink you > have another filter, this will overwrite the one specified in the > embed code. > >> >> That said, reference point in milliseconds appeared on charts >> recently, that somewhat makes it less of a problem for me. > > ;) > > But anyway try the solution before, it will fit better your case. > >> >>> The relative representation allows the user to focus on change in >>> the RTT over time and geographic space, instead of a pure comparison >>> among milliseconds of the various probes. >>> Following the user requests and according also to our internal use, >>> this is the most common use case, especially in case of outage analysis. >> My (mis)use case is different: I'm trying to monitor one particular >> link that's important for me, using a single probe and multiple >> nearby destinations. In this case absolute values matter: relative >> charts may look absolutely normal while absolute values are elevated >> from 1..2 to 10+ milliseconds because to link overload which is not good. >> > > Let me know if everything is fine! > > Ciao, > Massimo > >> -- >> >> With Best Regards, >> Marat Khalili >> >> On 09/05/16 18:25, Massimo Candela wrote: >>> Hi Marat, >>> >>>> On 13 Apr 2016, at 10:23, Marat Khalili wrote: >>>> >>>> I'm using LatencyMON >>>> widget to monitor >>>> my network performance. It's very convenient. Unfortunately, it >>>> always loads with latency shown in %% (of what?), not in >>>> milliseconds, so I have to make one extra click in order to view >>>> actual milliseconds. Is there some hidden switch that would make >>>> milliseconds the default? Shouldn't it be initially default in the >>>> first place? >>> >>> >>> Thanks for your comment, I will try to answer and give my opinion. >>> >>> Here you can find the documentation: >>> https://atlas.ripe.net/docs/tools-latencymon/ >>> According to it: "The relative representation shows, in percentages, >>> how the values behave compared to the baseline, which is the minimum >>> latency collected in the time range for the specific graph. Note >>> that outliers have been removed. >>> For example, if the latencies collected oscillate between 30 and 90 >>> ms, the y-axis will have a range between 0 and 200%, as 30 ms will >>> be considered the baseline and 90 ms represents an increase of 200% >>> over 30 ms.? >>> >>> The relative representation allows the user to focus on change in >>> the RTT over time and geographic space, instead of a pure comparison >>> among milliseconds of the various probes. >>> Following the user requests and according also to our internal use, >>> this is the most common use case, especially in case of outage analysis. >>> For example if you have a probe in Canada and one in Italy and the >>> target used in the measurement is in Germany, you would expect to >>> have some ms more from the one in Canada: this information it?s just >>> going to pollute the graphs. >>> Probably if something happens on the network you would like to know >>> which probes were affected and how. So what is the difference in RTT >>> compared to what is considered ?normal? from that source. >>> >>> You can anyway force to open the measurement in ms (the same goes >>> for all the other parameters) if you embed the widget in your html >>> page/monitor/dashboard. >>> >>> Sorry for the delay of the answer, for more information feel free to >>> contact me personally. >>> >>> Ciao, >>> Massimo >>> >>> >>> >>>> >>>> -- >>>> >>>> With Best Regards, >>>> Marat Khalili >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Tue May 10 14:56:00 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 10 May 2016 14:56:00 +0200 Subject: [atlas] SixXS issues In-Reply-To: References: Message-ID: <5731DA60.4080605@ripe.net> Hi, On 2016/05/05 15:11 , Alison Wheeler wrote: > I received my second probe* yesterday (different ASNs) and it is connects via SixXS for IPv6 as the ISP isn't supplying native v6 (despite repeatedly asking when they will catch up on something around for twenty years!). It booted fine and the appear no issues with the IPv4 connectivity but the v6 is going up and down every few minutes (for around the same period.) > > Not finding anything relevant after searching the forum (nor on google) I'm trying to discover why this might be. My other machines are not experiencing any difficulty with v6 connectivity and the probe is connected to the same 16-port switch as everything else. > > Suggestions of what to investigate next very welcome! It seems that your IPv6 connection has issues. Around the time the ssh connection fails, I also see IPv6 traceroutes with problems. But it is relatively far from the probe, so it is hard to be sure about the source of the problem. One option would be run a traceroute on your probe with relatively high frequency (once a minute) to see if you can spot any pattern in the traceroute output. Philip From mir at ripe.net Tue May 10 16:47:54 2016 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 10 May 2016 16:47:54 +0200 Subject: [atlas] New on RIPE Labs: Using RIPE Atlas to Debug Network Connectivity Problems In-Reply-To: <89215035-3573-0cbb-59da-7dd21625f33f@ripe.net> References: <89215035-3573-0cbb-59da-7dd21625f33f@ripe.net> Message-ID: <945fef46-88f9-53b9-1eff-2f2b004efb5d@ripe.net> Dear colleagues, Please find this new article by St?phane Bortzmeyer on RIPE Labs where he explains how he used RIPE Atlas probes, the official RIP Atlas API and custom scripts, to debug network issues: https://labs.ripe.net/Members/stephane_bortzmeyer/using-ripe-atlas-to-debug-network-connectivity-problems?pk_campaign=labs&pk_kwd=list-atlas Kind regards, Mirjam Kuehne RIPE NCC From rolf.sommerhalder at alumni.ethz.ch Wed May 11 10:07:22 2016 From: rolf.sommerhalder at alumni.ethz.ch (Rolf Sommerhalder) Date: Wed, 11 May 2016 10:07:22 +0200 Subject: [atlas] SixXS issues In-Reply-To: <5731DA60.4080605@ripe.net> References: <5731DA60.4080605@ripe.net> Message-ID: Hi Philip, On Tue, May 10, 2016 at 2:56 PM, Philip Homburg wrote: > It seems that your IPv6 connection has issues. Around the time the ssh > connection fails, I also see IPv6 traceroutes with problems. But it is > relatively far from the probe, so it is hard to be sure about the source > of the problem. Thanks for looking into this. I have just noticed that my v3 Probe #16258 now also has a problem with IPv6. But its in a different site with quite a different setup, which is still under construction, and I plan to look after it later today :-) Just to make sure we are talking about the same v1 Probe #2922 which sits at home (on a DOCSIS cable connection, behind a NAT firewall). This is the one which had worked quite stable for months, even years, also through the SixXs tunnel. Something must have changed earlier this year when it began to go down and up every few minutes, most likely due to some (new?) issue with IPv6. Did you test indeed #2922? And from which side did you origin your traceroutes on IPv6, e.g. from this probe, or to this probe from some other location? Thanks, Rolf From philip.homburg at ripe.net Wed May 11 12:08:48 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 11 May 2016 12:08:48 +0200 Subject: [atlas] SixXS issues In-Reply-To: References: <5731DA60.4080605@ripe.net> Message-ID: <573304B0.1050609@ripe.net> On 2016/05/11 10:07 , Rolf Sommerhalder wrote: > Just to make sure we are talking about the same v1 Probe #2922 which > sits at home (on a DOCSIS cable connection, behind a NAT firewall). > This is the one which had worked quite stable for months, even years, > also through the SixXs tunnel. Something must have changed earlier > this year when it began to go down and up every few minutes, most > likely due to some (new?) issue with IPv6. It seems that for this probe the tunnel is often down. I.e., traceroute shows the first hop and nothing more. Philip From pvlaar at afilias.info Wed May 11 12:25:53 2016 From: pvlaar at afilias.info (Paul Vlaar) Date: Wed, 11 May 2016 12:25:53 +0200 Subject: [atlas] probe congestion? Message-ID: <573308B1.4030307@afilias.info> Hi all, while running a DNS UDM on a fixed set of (reused from a previous UDM) probes, I noticed the following. When I start 6 UDMs against the same set using the web UI, as a one-off measurement, starting "now", the RTTs for all of the measurements shoots up on all of the probes (500-1000+ ms). When I start the 6 tests individually, the RTTs are much lower, and close to what I'd expect them to be. It appears to me that when multiple UDMs are scheduled on the same probe, these should be run in serial, not parallel, in order to not run into congestion issues. Or am I simply expecting the wrong behaviour, and should I not schedule one-off measurements in parallel in the first place? ~paul From v.bajpai at jacobs-university.de Wed May 11 12:46:31 2016 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Wed, 11 May 2016 10:46:31 +0000 Subject: [atlas] probe congestion? In-Reply-To: <573308B1.4030307@afilias.info> References: <573308B1.4030307@afilias.info> Message-ID: > On 11 May 2016, at 12:25, Paul Vlaar wrote: > > while running a DNS UDM on a fixed set of (reused from a previous UDM) probes, I noticed the following. When I start 6 UDMs against the same set using the web UI, as a one-off measurement, starting "now", the RTTs for all of the measurements shoots up on all of the probes (500-1000+ ms). When I start the 6 tests individually, the RTTs are much lower, and close to what I'd expect them to be. > > It appears to me that when multiple UDMs are scheduled on the same probe, these should be run in serial, not parallel, in order to not run into congestion issues. Or am I simply expecting the wrong behaviour, and should I not schedule one-off measurements in parallel in the first place? This is known [a, b]. RTT timestamps are applied in user-space. As such, if a probe is loaded with multiple measurements, the user-space time stamping will be delayed. These delays will be more pronounced on v1/v2 probes. v3 probes reduce the impact of user-space timestamping. As such, v3 probes are more suitable for latency measurements that require high precision accuracy. RIPE atlas system tags can be used to separate probes by h/w version. [a] http://www.sigcomm.org/sites/default/files/ccr/papers/2015/July/0000000-0000005.pdf [b] http://conferences.sigcomm.org/imc/2015/papers/p437.pdf > ~paul Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pvlaar at afilias.info Wed May 11 13:13:58 2016 From: pvlaar at afilias.info (Paul Vlaar) Date: Wed, 11 May 2016 13:13:58 +0200 Subject: [atlas] probe congestion? In-Reply-To: References: <573308B1.4030307@afilias.info> Message-ID: <573313F6.7000804@afilias.info> On 11/5/16 12:46, Bajpai, Vaibhav wrote: > This is known [a, b]. RTT timestamps are applied in user-space. > As such, if a probe is loaded with multiple measurements, the > user-space time stamping will be delayed. These delays will > be more pronounced on v1/v2 probes. Wow, this sounds pretty bad. The actual result is really huge, look at the differences here: - as part of a 6-fold one-off UDM using the same probe set: https://atlas.ripe.net/measurements/3793146/#!probes - as a one-off UDM as well, but with manual spacing of 20s in between scheduling the next of the set of 6 UDMs: https://atlas.ripe.net/measurements/3793054/#!probes This seems like a bug to me. The time between scheduling one-off measurements using the same probe is of influence on the RTT? How can I trust the RTT at all now? What if others are using the same probe at the same time? All scheduling, including one-offs are centrally managed, no? Why can't the Atlas scheduler make sure that probes don't get loaded with more than one UDM at a time? I'm no longer trusting any of the RTTs now. Can this also happen with periodical UDMs? > v3 probes reduce the impact of user-space timestamping. As such, v3 > probes are more suitable for latency measurements that require > high precision accuracy. RIPE atlas system tags can be used to > separate probes by h/w version. Aha. I'll have a try using just v3 probes. Thank you for the PDFs BTW, I will read those when I have more time. ~paul From pvlaar at afilias.info Wed May 11 13:57:02 2016 From: pvlaar at afilias.info (Paul Vlaar) Date: Wed, 11 May 2016 13:57:02 +0200 Subject: [atlas] probe congestion? In-Reply-To: References: <573308B1.4030307@afilias.info> Message-ID: <57331E0E.2010006@afilias.info> Same thing here, I just did another test. Ran 7 UDMs in parallel for SOA ripe.net @ manus.authdns.ripe.net, the result of one of those: https://atlas.ripe.net/measurements/3793292/#!probes Compared to running another one, but on its own w/o scheduling others in the same run: https://atlas.ripe.net/measurements/3793293/#!probes I'd call this a bug, or at least something to somehow work around, but not sure how, yet. ~paul From daniel.karrenberg at ripe.net Wed May 11 14:06:12 2016 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 11 May 2016 14:06:12 +0200 Subject: [atlas] probe congestion? In-Reply-To: <57331E0E.2010006@afilias.info> References: <573308B1.4030307@afilias.info> <57331E0E.2010006@afilias.info> Message-ID: One-offs are not intended to be used like this. The emphasis with them is to schedule as quickly as possible *no matter what*. This is for quick look-see work. Not for repeated measurements on the same set of probes. If you want to schedule that much from an indentical set of probes, do not use one-offs. Daniel On 11.05.16 13:57 , Paul Vlaar wrote: > Same thing here, I just did another test. Ran 7 UDMs in parallel for SOA > ripe.net @ manus.authdns.ripe.net, the result of one of those: > > https://atlas.ripe.net/measurements/3793292/#!probes > > Compared to running another one, but on its own w/o scheduling others in > the same run: > > https://atlas.ripe.net/measurements/3793293/#!probes > > I'd call this a bug, or at least something to somehow work around, but > not sure how, yet. > > ~paul > > From philip.homburg at ripe.net Wed May 11 14:07:11 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 11 May 2016 14:07:11 +0200 Subject: [atlas] probe congestion? In-Reply-To: <573313F6.7000804@afilias.info> References: <573308B1.4030307@afilias.info> <573313F6.7000804@afilias.info> Message-ID: <5733206F.6010300@ripe.net> On 2016/05/11 13:13 , Paul Vlaar wrote: > This seems like a bug to me. The time between scheduling one-off > measurements using the same probe is of influence on the RTT? How can I > trust the RTT at all now? What if others are using the same probe at the > same time? Statistically speaking the probes are idle, so the chance that your oneoff arrives at the probe at the same time as one from someone else is extremely low. The probe tries to execute 10 oneoffs in parallel. But considering that one average the probes are idle, it may be effective to avoid parallelism and run oneoffs sequentially. Philip From v.bajpai at jacobs-university.de Wed May 11 14:51:44 2016 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Wed, 11 May 2016 12:51:44 +0000 Subject: [atlas] probe congestion? In-Reply-To: <573313F6.7000804@afilias.info> References: <573308B1.4030307@afilias.info> <573313F6.7000804@afilias.info> Message-ID: <07036D20-7ACF-46B6-84C4-D50D273778E3@jacobs-university.de> > On 11 May 2016, at 13:13, Paul Vlaar wrote: > > On 11/5/16 12:46, Bajpai, Vaibhav wrote: >> This is known [a, b]. RTT timestamps are applied in user-space. >> As such, if a probe is loaded with multiple measurements, the >> user-space time stamping will be delayed. These delays will >> be more pronounced on v1/v2 probes. > > Wow, this sounds pretty bad. The actual result is really huge, look at the differences here: > > - as part of a 6-fold one-off UDM using the same probe set: > > https://atlas.ripe.net/measurements/3793146/#!probes > > - as a one-off UDM as well, but with manual spacing of 20s in between scheduling the next of the set of 6 UDMs: > > https://atlas.ripe.net/measurements/3793054/#!probes This includes three v3 probes. Note, how they show comparable latencies in both measurements unlike v1/v2 probes. Fig. 4 in [a] will tell you the probe ID ranges for each h/w revision. > This seems like a bug to me. The time between scheduling one-off > measurements using the same probe is of influence on the RTT? > How can I trust the RTT at all now? It?s generally not useful to draw any conclusions from one-off latency measurements. Run them for a longer period to get some representativeness and then look at the distributions of RTTs across the measurement duration. > What if others are using the same probe at the same time? RIPE Atlas does not provide this guarantee. You have to be prepared that your measurements are running in an uncontrolled setting. > All scheduling, including one-offs are centrally managed, no? Why > can't the Atlas scheduler make sure that probes don't get loaded > with more than one UDM at a time? I'm no longer trusting any of > the RTTs now. Can this also happen with periodical UDMs? Careful vantage point selection and longitudinal measurements will give you reasonable RTT results. >> v3 probes reduce the impact of user-space timestamping. As such, v3 >> probes are more suitable for latency measurements that require >> high precision accuracy. RIPE atlas system tags can be used to >> separate probes by h/w version. > > Aha. I'll have a try using just v3 probes. > > Thank you for the PDFs BTW, I will read those when I have more time. > > ~paul [a] http://www.sigcomm.org/sites/default/files/ccr/papers/2015/July/0000000-0000005.pdf =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From marc.sanchez at csuc.cat Wed May 11 17:52:06 2016 From: marc.sanchez at csuc.cat (Marc Sanchez) Date: Wed, 11 May 2016 17:52:06 +0200 Subject: [atlas] Number of probes Message-ID: I'm new in RIPE and I don't know it enough deeper. I need to check the state of several networks and I'm wondering how many probes should I need to measure a ping between two ASN. Could be enough using just one probe for each measurement? Sorry for the inconvenience. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From wenqin.shao at telecom-paristech.fr Wed May 11 18:03:45 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin Shao) Date: Wed, 11 May 2016 18:03:45 +0200 (CEST) Subject: [atlas] Number of probes In-Reply-To: References: Message-ID: <1317848896.53706228.1462982625973.JavaMail.zimbra@enst.fr> Hello Marc, It depends what you are looking for. Though the same AS path is measured between two ASes, the IP level paths could be different, which leads to different RTT behaviour. I analysed the RTT over 12h between 100 probes in AS3215 and m-root. The resulted times series demonstrate different level of variation. Further, it turned out that most variation in end2end RTT measurements takes place in access network, with the help of traceroute. So if you are looking to quantify the performance of AS level path, choose the ping trace with the least variation. For more detail, W. Shao, J.-L. Rougier, F. Devienne, and M. Viste, ?Improve Round-Trip Time Measurement Quality via Clustering in Inter-Domain Traffic Engineering,? no. AnNet, pp. 1105?1108, 2016. My two cents, wenqin ----- Mail original ----- De: "Marc Sanchez" ?: ripe-atlas at ripe.net Envoy?: Mercredi 11 Mai 2016 17:52:06 Objet: [atlas] Number of probes I'm new in RIPE and I don't know it enough deeper. I need to check the state of several networks and I'm wondering how many probes should I need to measure a ping between two ASN. Could be enough using just one probe for each measurement? Sorry for the inconvenience. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From v.bajpai at jacobs-university.de Thu May 12 16:03:03 2016 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Thu, 12 May 2016 14:03:03 +0000 Subject: [atlas] [dagstuhl seminar]: global measurements: practice and experience Message-ID: <537B94E0-691E-4745-BCA1-B2F03C408D7F@jacobs-university.de> Dear RIPE Atlas / MAT WG -- sorry for cross-posting. A SIGCOMM CCR article summarising the Dagstuhl seminar on ?Global Measurements: Practice and Experience? just came online [a]. Thought to share it with you: [a] http://www.sigcomm.org/sites/default/files/ccr/papers/2016/April/0000000-0000004.pdf Background: ===================== We recently helped organise a Dagstuhl seminar on Global Measurements: Practice and Experience [b] from January 04 ? 07, 2016. This was a followup of the seminar on Global Measurement Framework [c] which focused on the development of global Internet measurement platforms and associated metrics. [b] http://www.dagstuhl.de/16012 [c] http://www.dagstuhl.de/13472 The second seminar aimed at discussing the practical experience gained with building global measurement platforms. It brought together people who are actively involved in the design and maintenance of global measurement systems, who do research on the data delivered by global measurement systems, and who use data derived from global measurement systems in order to manage networks or services or as input for regulatory decisions. ===================== Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mhi at ionescu.de Fri May 13 12:20:47 2016 From: mhi at ionescu.de (Michael Ionescu) Date: Fri, 13 May 2016 12:20:47 +0200 Subject: [atlas] USB drive In-Reply-To: <56FBCC90.8090801@ionescu.de> References: <56FB98E3.4020702@ionescu.de> <56FBBD89.1030909@ripe.net> <56FBCC90.8090801@ionescu.de> Message-ID: <037393c0-3f97-385a-ddb8-6cef4f62effd@ionescu.de> Hi, I need to follow up on this once more... The same probe, which had now been working again for several weeks after it reformatted its drive, I have now found the drive to be read-only. After replacing the drive with a new one, the probe is once again fine. While troubleshooting I have found that the probe does not connect as long as there is no functioning drive present. This makes troubleshooting unnecessarily difficult. I would suggest adding a couple of (SOS?) messages that would run regardless of the presence of a drive, such as: - detected no USB drive on bootup - detected insertion of USB drive - detected removal of USB drive - detected read-only USB drive - Starting fsck on USB drive - Ended fsck on USB drive (possibly indicating success/failure) - Starting to reformat USB drive - Ended reformatting USB drive (possibly indicating success/failure) and possibliy something that would point towards a corrupt FS - if that is easily detectable, for instance by checking the integrity of a known file within the FS. Just my 2ct. Michael On 30.03.2016 13:50, Philip Homburg wrote: > Hi Michael, > [...] > In general, the probe doesn't care what is on the USB stick. So wiping > or formatting the stick is not needed. > > There is at the moment one rare exception. The filesystem can go corrupt > to the point the fsck hangs. > [...] > Philip From annikaw at penguinfriends.org Wed May 18 10:29:00 2016 From: annikaw at penguinfriends.org (Annika Wickert) Date: Wed, 18 May 2016 10:29:00 +0200 Subject: [atlas] Adding additional probes to existing measurement or exchange them Message-ID: <573C27CC.6090107@penguinfriends.org> Hi everybody, I just stumbled across this problem, that I want to exchange probes on a actual running measurement because some of the probes I defined 2weeks ago went offline. And I want other probes to take over their job. Is that possible in any way? Cheers, Annika Wickert From astrikos at ripe.net Wed May 18 10:54:17 2016 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 18 May 2016 10:54:17 +0200 Subject: [atlas] Adding additional probes to existing measurement or exchange them In-Reply-To: <573C27CC.6090107@penguinfriends.org> References: <573C27CC.6090107@penguinfriends.org> Message-ID: <3ffa1119-8d89-f398-15fe-28740bec6f47@ripe.net> Hi Annika, we have a special API for this. You can take a look at: https://atlas.ripe.net/docs/api/v2/manual/participation_requests.html And using python you can use: http://ripe-atlas-cousteau.readthedocs.io/en/master/use.html#changing-measurement-sources Cheers, Andreas On 18/05/16 10:29, Annika Wickert wrote: > Hi everybody, > > I just stumbled across this problem, that I want to exchange probes on > a actual running measurement because some of the probes I defined > 2weeks ago went offline. And I want other probes to take over their job. > > Is that possible in any way? > > Cheers, > Annika Wickert > From annikaw at penguinfriends.org Wed May 18 10:58:02 2016 From: annikaw at penguinfriends.org (Annika Wickert) Date: Wed, 18 May 2016 10:58:02 +0200 Subject: [atlas] Adding additional probes to existing measurement or exchange them In-Reply-To: <3ffa1119-8d89-f398-15fe-28740bec6f47@ripe.net> References: <573C27CC.6090107@penguinfriends.org> <3ffa1119-8d89-f398-15fe-28740bec6f47@ripe.net> Message-ID: <573C2E9A.90406@penguinfriends.org> Hi Andreas, thank you :). Was searching for it in the web fronted. Should have searched first in the API ;). CHeers, Annika On 18/05/16 10:54, Andreas Strikos wrote: > Hi Annika, > > we have a special API for this. You can take a look at: > https://atlas.ripe.net/docs/api/v2/manual/participation_requests.html > > And using python you can use: > http://ripe-atlas-cousteau.readthedocs.io/en/master/use.html#changing-measurement-sources > > > Cheers, > Andreas > > On 18/05/16 10:29, Annika Wickert wrote: >> Hi everybody, >> >> I just stumbled across this problem, that I want to exchange probes >> on a actual running measurement because some of the probes I defined >> 2weeks ago went offline. And I want other probes to take over their job. >> >> Is that possible in any way? >> >> Cheers, >> Annika Wickert >> > From Rafal.Jankowski at thomsonreuters.com Wed May 18 13:52:17 2016 From: Rafal.Jankowski at thomsonreuters.com (Rafal.Jankowski at thomsonreuters.com) Date: Wed, 18 May 2016 11:52:17 +0000 Subject: [atlas] evaluating ripe atlas Message-ID: <634D66B732BF1341916FCBD902B868A6118AF2E8@C111WBSLMBX06.ERF.thomson.com> Dear Ripe Atlas Users, I would like to evaluate ripe atlas features. Is there any quick and simple way to earn credits? From what I can see becoming sponsorship begins from 1000 EUR which is above my budget for evaluating the tool. Hosting probe is not something feasible for me at the moment. Is there any option to buy credits for something like 100 EUR? Also I wanted to see webinar recording https://www.youtube.com/watch?v=oJMFGuM0kMo linked on https://atlas.ripe.net/resources/training-and-materials/ but it seems to be unavailable. Regards, Rafa? ________________________________ This e-mail is for the sole use of the intended recipient and contains information that may be privileged and/or confidential. If you are not an intended recipient, please notify the sender by return e-mail and delete this e-mail and any attachments. Certain required legal entity disclosures can be accessed on our website. -------------- next part -------------- An HTML attachment was scrubbed... URL: From annikaw at penguinfriends.org Wed May 18 14:07:11 2016 From: annikaw at penguinfriends.org (Annika Wickert) Date: Wed, 18 May 2016 14:07:11 +0200 Subject: [atlas] evaluating ripe atlas In-Reply-To: <634D66B732BF1341916FCBD902B868A6118AF2E8@C111WBSLMBX06.ERF.thomson.com> References: <634D66B732BF1341916FCBD902B868A6118AF2E8@C111WBSLMBX06.ERF.thomson.com> Message-ID: <573C5AEF.1000209@penguinfriends.org> Hi, normally credits are earned by hosting probes or becoming a LIR. How many credits would you need for your tests? Maybe someone has some spare ones to send to you ;). Cheers, Annika On 18/05/16 13:52, Rafal.Jankowski at thomsonreuters.com wrote: > > Dear Ripe Atlas Users, > > I would like to evaluate ripe atlas features. Is there any quick and > simple way to earn credits? From what I can see becoming sponsorship > begins from 1000 EUR which is above my budget for evaluating the tool. > Hosting probe is not something feasible for me at the moment. Is > there any option to buy credits for something like 100 EUR? Also I > wanted to see webinar recording > https://www.youtube.com/watch?v=oJMFGuM0kMo linked on > https://atlas.ripe.net/resources/training-and-materials/ but it seems > to be unavailable. > > Regards, > > Rafa? > > > ------------------------------------------------------------------------ > > This e-mail is for the sole use of the intended recipient and contains > information that may be privileged and/or confidential. If you are not > an intended recipient, please notify the sender by return e-mail and > delete this e-mail and any attachments. Certain required legal entity > disclosures can be accessed on our website. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkh at rqc.ru Wed May 18 14:08:37 2016 From: mkh at rqc.ru (Marat Khalili) Date: Wed, 18 May 2016 15:08:37 +0300 Subject: [atlas] evaluating ripe atlas In-Reply-To: <634D66B732BF1341916FCBD902B868A6118AF2E8@C111WBSLMBX06.ERF.thomson.com> References: <634D66B732BF1341916FCBD902B868A6118AF2E8@C111WBSLMBX06.ERF.thomson.com> Message-ID: <573C5B45.10003@rqc.ru> Hello Rafa?, How many do you need and what for? I have some spare credits, other people here may have them too. > Hosting probe is not something feasible for me at the moment. I wonder why. All you need is USB charger and internet connection. -- With Best Regards, Marat Khalili On 18/05/16 14:52, Rafal.Jankowski at thomsonreuters.com wrote: > > Dear Ripe Atlas Users, > > I would like to evaluate ripe atlas features. Is there any quick and > simple way to earn credits? From what I can see becoming sponsorship > begins from 1000 EUR which is above my budget for evaluating the tool. > Hosting probe is not something feasible for me at the moment. Is > there any option to buy credits for something like 100 EUR? Also I > wanted to see webinar recording > https://www.youtube.com/watch?v=oJMFGuM0kMo linked on > https://atlas.ripe.net/resources/training-and-materials/ but it seems > to be unavailable. > > Regards, > > Rafa? > > > ------------------------------------------------------------------------ > > This e-mail is for the sole use of the intended recipient and contains > information that may be privileged and/or confidential. If you are not > an intended recipient, please notify the sender by return e-mail and > delete this e-mail and any attachments. Certain required legal entity > disclosures can be accessed on our website. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at fersing.eu Wed May 18 14:19:34 2016 From: ripe at fersing.eu (Boris Fersing) Date: Wed, 18 May 2016 12:19:34 +0000 Subject: [atlas] evaluating ripe atlas In-Reply-To: <573C5B45.10003@rqc.ru> References: <573C5B45.10003@rqc.ru> <634D66B732BF1341916FCBD902B868A6118AF2E8@C111WBSLMBX06.ERF.thomson.com> Message-ID: <605861d1aeb5614a198488a3f4ec235f@rainloop.fersing.net> Hi Rafal, I can also donate some credits, let me know. Boris May 18 2016 8:09 AM, "Marat Khalili" wrote: Hello Rafa?, How many do you need and what for? I have some spare credits, other people here may have them too. Hosting probe is not something feasible for me at the moment. I wonder why. All you need is USB charger and internet connection. -- With Best Regards, Marat Khalili On 18/05/16 14:52, Rafal.Jankowski at thomsonreuters.com (mailto:Rafal.Jankowski at thomsonreuters.com) wrote: Dear Ripe Atlas Users, I would like to evaluate ripe atlas features. Is there any quick and simple way to earn credits? From what I can see becoming sponsorship begins from 1000 EUR which is above my budget for evaluating the tool. Hosting probe is not something feasible for me at the moment. Is there any option to buy credits for something like 100 EUR? Also I wanted to see webinar recording https://www.youtube.com/watch?v=oJMFGuM0kMo (https://www.youtube.com/watch?v=oJMFGuM0kMo) linked on https://atlas.ripe.net/resources/training-and-materials/ (https://atlas.ripe.net/resources/training-and-materials/) but it seems to be unavailable. Regards, Rafa? ------------------------------------ This e-mail is for the sole use of the intended recipient and contains information that may be privileged and/or confidential. If you are not an intended recipient, please notify the sender by return e-mail and delete this e-mail and any attachments. Certain required legal entity disclosures can be accessed on our website. (http://site.thomsonreuters.com/site/disclosures/) -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.bajpai at jacobs-university.de Wed May 18 15:07:25 2016 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Wed, 18 May 2016 13:07:25 +0000 Subject: [atlas] probe coverage map? Message-ID: <6F8DFC76-8D29-44C6-AEFA-0C81740758FF@jacobs-university.de> Hello, What happened to the probe coverage map that showed number of probes at different level of details depending on the zoomed-in state of the map? ? I have an earlier screenshot [a] (2015) to explain what I mean. It was a very nice plot. [a] http://i.imgur.com/d0tI1qP.png I was looking for a probe coverage map to put in one of my slides. I ended up using [b], but I miss [a]. [b] https://www-static.ripe.net/static/rnd-ui/atlas/static/page/img/allprobes.png Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jared at puck.nether.net Wed May 18 15:09:52 2016 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 18 May 2016 09:09:52 -0400 Subject: [atlas] evaluating ripe atlas In-Reply-To: <605861d1aeb5614a198488a3f4ec235f@rainloop.fersing.net> References: <573C5B45.10003@rqc.ru> <634D66B732BF1341916FCBD902B868A6118AF2E8@C111WBSLMBX06.ERF.thomson.com> <605861d1aeb5614a198488a3f4ec235f@rainloop.fersing.net> Message-ID: I will hand out 10m credits to folks who email me a proper address. Jared Mauch > On May 18, 2016, at 8:19 AM, Boris Fersing wrote: > > Hi Rafal, > > I can also donate some credits, let me know. > > Boris > > May 18 2016 8:09 AM, "Marat Khalili" wrote: > Hello Rafa?, > > How many do you need and what for? I have some spare credits, other people here may have them too. > > > >> >> Hosting probe is not something feasible for me at the moment. > I wonder why. All you need is USB charger and internet connection. > > -- > > With Best Regards, > Marat Khalili > >> On 18/05/16 14:52, Rafal.Jankowski at thomsonreuters.com wrote: >> >> Dear Ripe Atlas Users, >> I would like to evaluate ripe atlas features. Is there any quick and simple way to earn credits? From what I can see becoming sponsorship begins from 1000 EUR which is above my budget for evaluating the tool. Hosting probe is not something feasible for me at the moment. Is there any option to buy credits for something like 100 EUR? Also I wanted to see webinar recording https://www.youtube.com/watch?v=oJMFGuM0kMo linked on https://atlas.ripe.net/resources/training-and-materials/ but it seems to be unavailable. >> Regards, >> Rafa? >> >> >> This e-mail is for the sole use of the intended recipient and contains information that may be privileged and/or confidential. If you are not an intended recipient, please notify the sender by return e-mail and delete this e-mail and any attachments. Certain required legal entity disclosures can be accessed on our website. -------------- next part -------------- An HTML attachment was scrubbed... URL: From canadatechguy at gmail.com Wed May 18 15:11:13 2016 From: canadatechguy at gmail.com (Tanner Ryan) Date: Wed, 18 May 2016 09:11:13 -0400 Subject: [atlas] probe coverage map? In-Reply-To: <6F8DFC76-8D29-44C6-AEFA-0C81740758FF@jacobs-university.de> References: <6F8DFC76-8D29-44C6-AEFA-0C81740758FF@jacobs-university.de> Message-ID: Is this what you are looking for? https://atlas.ripe.net/results/maps/network-coverage/ On Wednesday, May 18, 2016, Bajpai, Vaibhav wrote: > Hello, > > What happened to the probe coverage map that showed number of probes > at different level of details depending on the zoomed-in state of > the map? ? I have an earlier screenshot [a] (2015) to explain what > I mean. It was a very nice plot. > > [a] http://i.imgur.com/d0tI1qP.png > > I was looking for a probe coverage map to put in one of my slides. > I ended up using [b], but I miss [a]. > > [b] > https://www-static.ripe.net/static/rnd-ui/atlas/static/page/img/allprobes.png > > Best, Vaibhav > > =================================== > Vaibhav Bajpai > www.vaibhavbajpai.com > > Room 91, Research I > School of Engineering and Sciences > Jacobs University Bremen, Germany > =================================== > -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.bajpai at jacobs-university.de Wed May 18 15:35:02 2016 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Wed, 18 May 2016 13:35:02 +0000 Subject: [atlas] probe coverage map? In-Reply-To: References: <6F8DFC76-8D29-44C6-AEFA-0C81740758FF@jacobs-university.de> Message-ID: <2F0038D0-C956-4535-83F1-467B9D899A9A@jacobs-university.de> > On 18 May 2016, at 15:11, Tanner Ryan wrote: > > Is this what you are looking for? > https://atlas.ripe.net/results/maps/network-coverage Nope. It used to look like this: http://i.imgur.com/d0tI1qP.png Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mir at ripe.net Wed May 18 16:51:19 2016 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 18 May 2016 16:51:19 +0200 Subject: [atlas] New on RIPE Labs: Pinpointing Delay and Forwarding Anomalies using RIPE Atlas Built-in Measurements In-Reply-To: <36eff228-1304-0c78-7d2f-10b5cba79134@ripe.net> References: <36eff228-1304-0c78-7d2f-10b5cba79134@ripe.net> Message-ID: <645ac7c6-38c4-28b1-a159-afeb89c21a89@ripe.net> Dear colleagues, Detecting network disruptions is a recurring problem. Clearly locating performance degradation is an important step in debugging and subsequently fixing connectivity issues. In this new RIPE Labs article the authors propose a set of complementary methods to detect network disruptions from traceroute measurements created by RIPE Atlas Built-In Measurements: https://labs.ripe.net/Members/romain_fontugne/pinpointing-delay-and-forwarding-anomalies-in-ripe-atlas-built-in-measurements?pk_campaign=labs&pk_kwd=list-atlas Kind regards, Mirjam Kuehne RIPE NCC From bengan at resilans.se Wed May 18 17:52:14 2016 From: bengan at resilans.se (=?UTF-8?B?QmVuZ3QgR8O2cmTDqW4=?=) Date: Wed, 18 May 2016 17:52:14 +0200 Subject: [atlas] probe coverage map? In-Reply-To: <2F0038D0-C956-4535-83F1-467B9D899A9A@jacobs-university.de> References: <6F8DFC76-8D29-44C6-AEFA-0C81740758FF@jacobs-university.de> <2F0038D0-C956-4535-83F1-467B9D899A9A@jacobs-university.de> Message-ID: <573C8FAE.3070008@resilans.se> Den 2016-05-18 kl. 15:35, skrev Bajpai, Vaibhav: >> On 18 May 2016, at 15:11, Tanner Ryan wrote: >> >> Is this what you are looking for? >> https://atlas.ripe.net/results/maps/network-coverage > Nope. It used to look like this: http://i.imgur.com/d0tI1qP.png This link has a similar map. Try reach out to Vesna Manojlovic (becha) to see if it's still available as a heat map somewhere. https://labs.ripe.net/Members/becha/extending-ripe-atlas-reach regards, -- Bengt G?rd?n Resilans AB From bengan at resilans.se Wed May 18 17:59:46 2016 From: bengan at resilans.se (=?UTF-8?B?QmVuZ3QgR8O2cmTDqW4=?=) Date: Wed, 18 May 2016 17:59:46 +0200 Subject: [atlas] probe coverage map? In-Reply-To: <2F0038D0-C956-4535-83F1-467B9D899A9A@jacobs-university.de> References: <6F8DFC76-8D29-44C6-AEFA-0C81740758FF@jacobs-university.de> <2F0038D0-C956-4535-83F1-467B9D899A9A@jacobs-university.de> Message-ID: <573C9172.6070406@resilans.se> Den 2016-05-18 kl. 15:35, skrev Bajpai, Vaibhav: >> On 18 May 2016, at 15:11, Tanner Ryan wrote: >> >> Is this what you are looking for? >> https://atlas.ripe.net/results/maps/network-coverage Click the upper right corner in the map and choose watercolour. -- Bengt G?rd?n Resilans AB From BECHA at ripe.net Wed May 18 18:03:20 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 18 May 2016 18:03:20 +0200 Subject: [atlas] probe coverage map? In-Reply-To: <573C8FAE.3070008@resilans.se> References: <6F8DFC76-8D29-44C6-AEFA-0C81740758FF@jacobs-university.de> <2F0038D0-C956-4535-83F1-467B9D899A9A@jacobs-university.de> <573C8FAE.3070008@resilans.se> Message-ID: <573C9248.5070403@ripe.net> Hi Bengt, Vaibhav, all, On 18/05/16 17:52, Bengt G?rd?n wrote: > Den 2016-05-18 kl. 15:35, skrev Bajpai, Vaibhav: >>> On 18 May 2016, at 15:11, Tanner Ryan wrote: >>> >>> Is this what you are looking for? >>> https://atlas.ripe.net/results/maps/network-coverage >> Nope. It used to look like this: http://i.imgur.com/d0tI1qP.png > > This link has a similar map. Try reach out to Vesna Manojlovic (becha) > to see if it's still available as a heat map somewhere. > > https://labs.ripe.net/Members/becha/extending-ripe-atlas-reach We have moved away from the "doughnut" coverage map, since the user feedback was not very positive, and the performance was an issue too, with zooming in & out taking lots of resources. It's interesting to see that now there is a demand for such a map... Let me point you out to some Free Software tools that might help: 1) https://github.com/monrad/maera "Maera is a tool that is able to generate latency maps from RIPE ATLAS data. Some examples: http://monrad.github.io/maera/maera/2015/03/16/welcome-to-maera.html" 2) https://github.com/opendatacity/ripe-map & many more here: https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib/blob/master/README.md 3) Or something like this: http://ripeanchor.sdv.fr/ https://labs.ripe.net/Members/salim_gasmi/visualising-ripe-atlas-anchor-measurements If you can be more specific in what your need is, maybe we can help you further: are you interested in the number of probes per region? Per country? Regards, Vesna From woeber at cc.univie.ac.at Thu May 19 11:08:33 2016 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Thu, 19 May 2016 11:08:33 +0200 Subject: [atlas] evaluating ripe atlas In-Reply-To: <573C5B45.10003@rqc.ru> References: <634D66B732BF1341916FCBD902B868A6118AF2E8@C111WBSLMBX06.ERF.thomson.com> <573C5B45.10003@rqc.ru> Message-ID: <573D8291.8050905@cc.univie.ac.at> Hi Rafa?! On 2016-05-18 14:08, Marat Khalili wrote: > Hello Rafa?, > > How many do you need and what for? I have some spare credits, other people here may have them too. > >> Hosting probe is not something feasible for me at the moment. > I wonder why. So do I. I can imagine a set of ("good") reasons for some environments, but I'm still curious :-) Wilfried > All you need is USB charger and internet connection. > -- > > With Best Regards, > Marat Khalili From mkh at rqc.ru Thu May 19 15:52:18 2016 From: mkh at rqc.ru (Marat Khalili) Date: Thu, 19 May 2016 16:52:18 +0300 Subject: [atlas] Replacing flash key Message-ID: <573DC512.8010703@rqc.ru> My V3 probe (26656) disconnected yesterday, simple reboots didn't help. Suspecting problem with USB key I first tried to replace it with a new one. I took bog standard Transcend JetFlash 350 8Gb right out of the wrapping and inserted it into a started probe 10 minutes after boot. Did not format the flash key or alter it in any way, because someone previously said that it is not necessary. Unfortunately, probe did not come up, and the flash key seems unchanged after approximately 1 hour wait. What should I do to switch to a new flash key? Also, did someone tried connecting HDDs/SSDs, shouldn't they work better? (Probe did appear after I inserted previously used flash key into it, but I suspect problem will re-occur in the future, so I'd like to know a way to fix it more permanently.) -- With Best Regards, Marat Khalili -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at mtds.com Thu May 19 15:59:34 2016 From: karl at mtds.com (Karl U Stanzick) Date: Thu, 19 May 2016 14:59:34 +0100 (WEST) Subject: [atlas] Replacing flash key In-Reply-To: <573DC512.8010703@rqc.ru> References: <573DC512.8010703@rqc.ru> Message-ID: I am having the same problem Marat. On the website I followed the instructions (see attached) and am appearing in the SOS history, but not "Connected". I received an email from Atlas Support which told me to do the same thing with no result. Was up for 25 days now have been down more than two weeks. Ideas? -- |-Karl U. Stanzick |-Managing Director, MTDS |-in morocco 080200MTDS |-direct +212(0)537278811 |-mobile +212(0)661152688 |-14, rue 16 novembre |-Rabat 10080 Kingdom of Morocco On Thu, 19 May 2016, Marat Khalili wrote: > My V3 probe (26656) disconnected yesterday, simple reboots didn't help. > Suspecting problem with USB key I first tried to replace it with a new one. I > took bog standard Transcend JetFlash 350 8Gb right out of the wrapping and > inserted it into a started probe 10 minutes after boot. Did not format the > flash key or alter it in any way, because someone previously said that it is > not necessary. Unfortunately, probe did not come up, and the flash key seems > unchanged after approximately 1 hour wait. What should I do to switch to a > new flash key? Also, did someone tried connecting HDDs/SSDs, shouldn't they > work better? > > (Probe did appear after I inserted previously used flash key into it, but I > suspect problem will re-occur in the future, so I'd like to know a way to fix > it more permanently.) > > -- > > With Best Regards, > Marat Khalili > -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-05-19 at 14.56.55.png Type: image/png Size: 285626 bytes Desc: URL: From karsten_thomann at linfre.de Thu May 19 15:59:56 2016 From: karsten_thomann at linfre.de (Karsten Thomann) Date: Thu, 19 May 2016 15:59:56 +0200 Subject: [atlas] Replacing flash key In-Reply-To: <573DC512.8010703@rqc.ru> References: <573DC512.8010703@rqc.ru> Message-ID: <3065497.yZo2f1547m@e7240.linfre> Hi, do you use static IP's for the probe without any dhcp? My probe wasn't able to use the new USB key when it was attached to a network without dhcp (waited over 12hours). After it was connected to a port in another network with dhcp the probe recovered with the new usb key after some time. Kind regards Karsten Am Donnerstag, 19. Mai 2016, 16:52:18 CEST schrieb Marat Khalili: > My V3 probe (26656) disconnected yesterday, simple reboots didn't help. > Suspecting problem with USB key I first tried to replace it with a new > one. I took bog standard Transcend JetFlash 350 8Gb right out of the > wrapping and inserted it into a started probe 10 minutes after boot. Did > not format the flash key or alter it in any way, because someone > previously said that it is not necessary. Unfortunately, probe did not > come up, and the flash key seems unchanged after approximately 1 hour > wait. What should I do to switch to a new flash key? Also, did someone > tried connecting HDDs/SSDs, shouldn't they work better? > > (Probe did appear after I inserted previously used flash key into it, > but I suspect problem will re-occur in the future, so I'd like to know a > way to fix it more permanently.) > > -- > > With Best Regards, > Marat Khalili From ripe at fersing.eu Thu May 19 16:05:15 2016 From: ripe at fersing.eu (Boris Fersing) Date: Thu, 19 May 2016 14:05:15 +0000 Subject: [atlas] Replacing flash key In-Reply-To: <573DC512.8010703@rqc.ru> References: <573DC512.8010703@rqc.ru> Message-ID: <35b3a0e0bab4d6bc0d83a96668676bc7@rainloop.fersing.net> Hi Marat, You said you inserted the USB key 10 minutes after the probe boot. Have you tried to start the probe with the key already inserted? Cheers, Boris May 19 2016 9:53 AM, "Marat Khalili" wrote: My V3 probe (26656) disconnected yesterday, simple reboots didn't help. Suspecting problem with USB key I first tried to replace it with a new one. I took bog standard Transcend JetFlash 350 8Gb right out of the wrapping and inserted it into a started probe 10 minutes after boot. Did not format the flash key or alter it in any way, because someone previously said that it is not necessary. Unfortunately, probe did not come up, and the flash key seems unchanged after approximately 1 hour wait. What should I do to switch to a new flash key? Also, did someone tried connecting HDDs/SSDs, shouldn't they work better? (Probe did appear after I inserted previously used flash key into it, but I suspect problem will re-occur in the future, so I'd like to know a way to fix it more permanently.) -- With Best Regards, Marat Khalili -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkh at rqc.ru Thu May 19 16:06:40 2016 From: mkh at rqc.ru (Marat Khalili) Date: Thu, 19 May 2016 17:06:40 +0300 Subject: [atlas] Replacing flash key In-Reply-To: <3065497.yZo2f1547m@e7240.linfre> References: <573DC512.8010703@rqc.ru> <3065497.yZo2f1547m@e7240.linfre> Message-ID: <573DC870.4040308@rqc.ru> Hello Karsten, I use DHCP. Probe did obtain IP-address, responded to pings and showed some network activity, but status page on the ATLAS site reported it as disconnected. -- With Best Regards, Marat Khalili On 19/05/16 16:59, Karsten Thomann wrote: > Hi, > > do you use static IP's for the probe without any dhcp? > My probe wasn't able to use the new USB key when it was attached to a network > without dhcp (waited over 12hours). > After it was connected to a port in another network with dhcp the probe > recovered with the new usb key after some time. > > Kind regards > Karsten > > Am Donnerstag, 19. Mai 2016, 16:52:18 CEST schrieb Marat Khalili: >> My V3 probe (26656) disconnected yesterday, simple reboots didn't help. >> Suspecting problem with USB key I first tried to replace it with a new >> one. I took bog standard Transcend JetFlash 350 8Gb right out of the >> wrapping and inserted it into a started probe 10 minutes after boot. Did >> not format the flash key or alter it in any way, because someone >> previously said that it is not necessary. Unfortunately, probe did not >> come up, and the flash key seems unchanged after approximately 1 hour >> wait. What should I do to switch to a new flash key? Also, did someone >> tried connecting HDDs/SSDs, shouldn't they work better? >> >> (Probe did appear after I inserted previously used flash key into it, >> but I suspect problem will re-occur in the future, so I'd like to know a >> way to fix it more permanently.) >> >> -- >> >> With Best Regards, >> Marat Khalili > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkh at rqc.ru Thu May 19 16:10:55 2016 From: mkh at rqc.ru (Marat Khalili) Date: Thu, 19 May 2016 17:10:55 +0300 Subject: [atlas] Replacing flash key In-Reply-To: <35b3a0e0bab4d6bc0d83a96668676bc7@rainloop.fersing.net> References: <573DC512.8010703@rqc.ru> <35b3a0e0bab4d6bc0d83a96668676bc7@rainloop.fersing.net> Message-ID: <573DC96F.4030505@rqc.ru> Hello Boris, Do not remember exactly, but most likely I did reboot probe with the new key inserted at least once. In any case, I can do this test if you have some specific reasons to believe it will change something. -- With Best Regards, Marat Khalili On 19/05/16 17:05, Boris Fersing wrote: > Hi Marat, > > You said you inserted the USB key 10 minutes after the probe boot. > Have you tried to start the probe with the key already inserted? > > Cheers, > Boris > > May 19 2016 9:53 AM, "Marat Khalili" > wrote: > > My V3 probe (26656) disconnected yesterday, simple reboots didn't > help. Suspecting problem with USB key I first tried to replace it > with a new one. I took bog standard Transcend JetFlash 350 8Gb > right out of the wrapping and inserted it into a started probe 10 > minutes after boot. Did not format the flash key or alter it in > any way, because someone previously said that it is not necessary. > Unfortunately, probe did not come up, and the flash key seems > unchanged after approximately 1 hour wait. What should I do to > switch to a new flash key? Also, did someone tried connecting > HDDs/SSDs, shouldn't they work better? > > (Probe did appear after I inserted previously used flash key into > it, but I suspect problem will re-occur in the future, so I'd like > to know a way to fix it more permanently.) > > -- > > With Best Regards, > Marat Khalili > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at mtds.com Thu May 19 16:43:42 2016 From: karl at mtds.com (Karl U Stanzick) Date: Thu, 19 May 2016 15:43:42 +0100 (WEST) Subject: [atlas] Replacing flash key In-Reply-To: <573DC870.4040308@rqc.ru> References: <573DC512.8010703@rqc.ru> <3065497.yZo2f1547m@e7240.linfre> <573DC870.4040308@rqc.ru> Message-ID: Identical situation with me as well. Probe ID 26130. I noticed a System Tag was added that says Hardware problem suspected. Do you have that too Marat? -- |-Karl U. Stanzick |-Managing Director, MTDS |-in morocco 080200MTDS |-direct +212(0)537278811 |-mobile +212(0)661152688 |-14, rue 16 novembre |-Rabat 10080 Kingdom of Morocco On Thu, 19 May 2016, Marat Khalili wrote: > Hello Karsten, > > I use DHCP. Probe did obtain IP-address, responded to pings and showed some > network activity, but status page on the ATLAS site reported it as > disconnected. > > -- > > With Best Regards, > Marat Khalili > > On 19/05/16 16:59, Karsten Thomann wrote: >> Hi, >> >> do you use static IP's for the probe without any dhcp? >> My probe wasn't able to use the new USB key when it was attached to a >> network >> without dhcp (waited over 12hours). >> After it was connected to a port in another network with dhcp the probe >> recovered with the new usb key after some time. >> >> Kind regards >> Karsten >> >> Am Donnerstag, 19. Mai 2016, 16:52:18 CEST schrieb Marat Khalili: >>> My V3 probe (26656) disconnected yesterday, simple reboots didn't help. >>> Suspecting problem with USB key I first tried to replace it with a new >>> one. I took bog standard Transcend JetFlash 350 8Gb right out of the >>> wrapping and inserted it into a started probe 10 minutes after boot. Did >>> not format the flash key or alter it in any way, because someone >>> previously said that it is not necessary. Unfortunately, probe did not >>> come up, and the flash key seems unchanged after approximately 1 hour >>> wait. What should I do to switch to a new flash key? Also, did someone >>> tried connecting HDDs/SSDs, shouldn't they work better? >>> >>> (Probe did appear after I inserted previously used flash key into it, >>> but I suspect problem will re-occur in the future, so I'd like to know a >>> way to fix it more permanently.) >>> >>> -- >>> >>> With Best Regards, >>> Marat Khalili >> >> > > From ripe at fersing.eu Thu May 19 16:47:25 2016 From: ripe at fersing.eu (Boris Fersing) Date: Thu, 19 May 2016 14:47:25 +0000 Subject: [atlas] Replacing flash key In-Reply-To: <573DC96F.4030505@rqc.ru> References: <573DC96F.4030505@rqc.ru> <573DC512.8010703@rqc.ru> <35b3a0e0bab4d6bc0d83a96668676bc7@rainloop.fersing.net> Message-ID: <0050ad75ddc4521acd42b7eed05bcf4b@rainloop.fersing.net> Hi, I was asking because I had a similar issue recently. If I remember correctly, I inserted the USB key before starting the probe, and after few minutes I checked the USB key again and it was partitioned with 3 1GB partitions. I might also be wrong, because I was playing around with the USB key, but I think it's worth a try. Regards, Boris May 19 2016 10:11 AM, "Marat Khalili" wrote: Hello Boris, Do not remember exactly, but most likely I did reboot probe with the new key inserted at least once. In any case, I can do this test if you have some specific reasons to believe it will change something. -- With Best Regards, Marat Khalili On 19/05/16 17:05, Boris Fersing wrote: Hi Marat, You said you inserted the USB key 10 minutes after the probe boot. Have you tried to start the probe with the key already inserted? Cheers, Boris May 19 2016 9:53 AM, "Marat Khalili" wrote: My V3 probe (26656) disconnected yesterday, simple reboots didn't help. Suspecting problem with USB key I first tried to replace it with a new one. I took bog standard Transcend JetFlash 350 8Gb right out of the wrapping and inserted it into a started probe 10 minutes after boot. Did not format the flash key or alter it in any way, because someone previously said that it is not necessary. Unfortunately, probe did not come up, and the flash key seems unchanged after approximately 1 hour wait. What should I do to switch to a new flash key? Also, did someone tried connecting HDDs/SSDs, shouldn't they work better? (Probe did appear after I inserted previously used flash key into it, but I suspect problem will re-occur in the future, so I'd like to know a way to fix it more permanently.) -- With Best Regards, Marat Khalili -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkh at rqc.ru Thu May 19 16:54:02 2016 From: mkh at rqc.ru (Marat Khalili) Date: Thu, 19 May 2016 17:54:02 +0300 Subject: [atlas] Replacing flash key In-Reply-To: References: <573DC512.8010703@rqc.ru> <3065497.yZo2f1547m@e7240.linfre> <573DC870.4040308@rqc.ru> Message-ID: <573DD38A.6030707@rqc.ru> On 19/05/16 17:43, Karl U Stanzick wrote: > I noticed a System Tag was added that says Hardware problem > suspected. Do you have that too Marat? No, mine doesn't show one yet: https://atlas.ripe.net/probes/26656/#tab-general -- With Best Regards, Marat Khalili From mkh at rqc.ru Fri May 20 13:34:55 2016 From: mkh at rqc.ru (Marat Khalili) Date: Fri, 20 May 2016 14:34:55 +0300 Subject: [atlas] Replacing flash key In-Reply-To: <0050ad75ddc4521acd42b7eed05bcf4b@rainloop.fersing.net> References: <573DC96F.4030505@rqc.ru> <573DC512.8010703@rqc.ru> <35b3a0e0bab4d6bc0d83a96668676bc7@rainloop.fersing.net> <0050ad75ddc4521acd42b7eed05bcf4b@rainloop.fersing.net> Message-ID: <573EF65F.7000707@rqc.ru> I did the experiment, and it was successful: probe appeared 8 minutes after booting with a new flash key. I'd say we need more statistics, but sometimes it works. -- With Best Regards, Marat Khalili On 19/05/16 17:47, Boris Fersing wrote: > Hi, > > I was asking because I had a similar issue recently. If I remember > correctly, I inserted the USB key before starting the probe, and after > few minutes I checked the USB key again and it was partitioned with 3 > 1GB partitions. > > I might also be wrong, because I was playing around with the USB key, > but I think it's worth a try. > > Regards, > Boris > > May 19 2016 10:11 AM, "Marat Khalili" > wrote: > > Hello Boris, > > Do not remember exactly, but most likely I did reboot probe with > the new key inserted at least once. In any case, I can do this > test if you have some specific reasons to believe it will change > something. > -- > > With Best Regards, > Marat Khalili > On 19/05/16 17:05, Boris Fersing wrote: >> Hi Marat, >> >> You said you inserted the USB key 10 minutes after the probe >> boot. Have you tried to start the probe with the key already >> inserted? >> >> Cheers, >> Boris >> >> May 19 2016 9:53 AM, "Marat Khalili" > > wrote: >> >> My V3 probe (26656) disconnected yesterday, simple reboots >> didn't help. Suspecting problem with USB key I first tried to >> replace it with a new one. I took bog standard Transcend >> JetFlash 350 8Gb right out of the wrapping and inserted it >> into a started probe 10 minutes after boot. Did not format >> the flash key or alter it in any way, because someone >> previously said that it is not necessary. Unfortunately, >> probe did not come up, and the flash key seems unchanged >> after approximately 1 hour wait. What should I do to switch >> to a new flash key? Also, did someone tried connecting >> HDDs/SSDs, shouldn't they work better? >> >> (Probe did appear after I inserted previously used flash key >> into it, but I suspect problem will re-occur in the future, >> so I'd like to know a way to fix it more permanently.) >> >> -- >> >> With Best Regards, >> Marat Khalili >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhi at ionescu.de Fri May 20 14:37:44 2016 From: mhi at ionescu.de (Michael Ionescu) Date: Fri, 20 May 2016 14:37:44 +0200 Subject: [atlas] USB drive more harmful than helpful? Message-ID: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> >From both my own (short term) experience and from what's being written on this list, I'm getting the impression that the USB drive may be costing more than it's worth. I have in only about 3 months experienced multiple probe issues due to USB drives and there have been multiple threads on this list which suggest that I am far from alone. I will go so far as to suspect that a substantial number of disconnected and abandoned probes have similar issues, but the hosters may be unwilling or unable to spend the necessary time to investigate and resolve them. If the main reason for the drive is to cache data during unavailability of the command and control center, this may not be worth the effort. I would suggest making the drive optional. That may mean fewer data points from and/or fewer UDMs possible on those probes without a functioning drive. But it may also mean a couple thousand probes more connected and therefore available for measurements at all. I'm not saying that probes should not ask for their drives to be fixed/replaced, but it should not be a requirement for the probe to run. One might give an incentive to hosters to run their probes with functioning drives by giving less credits for connected probes without a drive. Any thoughts? Michael -- Sent from a mobile. Please excuse my brevity. // M: +49-163-6866568 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Fri May 20 14:53:46 2016 From: mir at ripe.net (=?iso-8859-1?q?Mirjam_K=FChne?=) Date: Fri, 20 May 2016 14:53:46 +0200 Subject: [atlas] New on RIPE Labs: There Is Gold in This Stream - Sifting Through Used RIPE Atlas Traceroute Results Message-ID: Dear colleagues, Please find a new article on RIPE Labs demonstrating the value of the results collected by RIPE Atlas independent of the original purpose for collecting them. Using all traceroute results from a particular day as an example, we first show that near real-time analysis of the result stream is feasible. Then we show that this has great potential for studying the packet layer of the Internet in general and for providing tools to network operators in particular. All this suggests a large and diverse potential for further work. https://labs.ripe.net/Members/dfk/there-is-gold-in-this-stream?pk_campaign=labs&pk_kwd=list-atlas Kind regards, Mirjam Kuehne RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From hank at efes.iucc.ac.il Fri May 20 14:57:10 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 20 May 2016 15:57:10 +0300 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> Message-ID: On 20/05/2016 15:37, Michael Ionescu wrote: Interesting idea to make the USB drive optional. Based on literature: https://en.wikipedia.org/wiki/USB_flash_drive#Failures https://askleo.com/can_a_usb_thumbdrive_wear_out/ - 10,000-100,000 http://cfgearblog.blogspot.co.il/2011/03/how-long-does-flash-drive-last_22.html - 10,000-1M Has anyone tested how many writes are going on to the ATLAS thumb drive? Perhaps with all the failures within a year of start, perhaps too many writes are taking place? Regards, Hank > >From both my own (short term) experience and from what's being > written on this list, I'm getting the impression that the USB drive > may be costing more than it's worth. > > I have in only about 3 months experienced multiple probe issues due to > USB drives and there have been multiple threads on this list which > suggest that I am far from alone. > > I will go so far as to suspect that a substantial number of > disconnected and abandoned probes have similar issues, but the hosters > may be unwilling or unable to spend the necessary time to investigate > and resolve them. > > If the main reason for the drive is to cache data during > unavailability of the command and control center, this may not be > worth the effort. > > I would suggest making the drive optional. That may mean fewer data > points from and/or fewer UDMs possible on those probes without a > functioning drive. But it may also mean a couple thousand probes more > connected and therefore available for measurements at all. > > I'm not saying that probes should not ask for their drives to be > fixed/replaced, but it should not be a requirement for the probe to > run. One might give an incentive to hosters to run their probes with > functioning drives by giving less credits for connected probes without > a drive. > > Any thoughts? > > Michael > -- > Sent from a mobile. Please excuse my brevity. // M: +49-163-6866568 From gert at space.net Fri May 20 15:06:32 2016 From: gert at space.net (Gert Doering) Date: Fri, 20 May 2016 15:06:32 +0200 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> Message-ID: <20160520130632.GK1755@Space.Net> Hi, On Fri, May 20, 2016 at 02:37:44PM +0200, Michael Ionescu wrote: > >From both my own (short term) experience and from what's being written on this list, I'm getting the impression that the USB drive may be costing more than it's worth. [..] > Any thoughts? The USB outages and the lack of proper guidance for probe hosts about the problem status and how to get the probes back has been my gripe #1 for a while now. So, yes, this needs fixing, one way or the other. 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: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From gil at magisto.com Fri May 20 15:10:03 2016 From: gil at magisto.com (Gil Bahat) Date: Fri, 20 May 2016 16:10:03 +0300 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: <20160520130632.GK1755@Space.Net> References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> <20160520130632.GK1755@Space.Net> Message-ID: +1. I lost most of the probes this way and I'm not really sure how to recover them - I need to ask for a batch of USB drives or ask all the hosts to remove them... can't this be handled better with a firmware replacement? I would at least then ask all the hosts to unplug the USB and leave the hosts as is. Gil On Fri, May 20, 2016 at 4:06 PM, Gert Doering wrote: > Hi, > > On Fri, May 20, 2016 at 02:37:44PM +0200, Michael Ionescu wrote: > > >From both my own (short term) experience and from what's being written > on this list, I'm getting the impression that the USB drive may be costing > more than it's worth. > [..] > > Any thoughts? > > The USB outages and the lack of proper guidance for probe hosts about > the problem status and how to get the probes back has been my gripe #1 > for a while now. > > So, yes, this needs fixing, one way or the other. > > 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 -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Fri May 20 15:58:06 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 20 May 2016 15:58:06 +0200 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> Message-ID: <573F17EE.3060208@ripe.net> On 2016/05/20 14:37 , Michael Ionescu wrote: > If the main reason for the drive is to cache data during unavailability > of the command and control center, this may not be worth the effort. No, the probe actually runs from the USB stick. The internal 4MB flash is just enough to initialize the USB stick in a secure way. And even that is already tricky. From philip.homburg at ripe.net Fri May 20 16:10:47 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 20 May 2016 16:10:47 +0200 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> Message-ID: <573F1AE7.3050902@ripe.net> On 2016/05/20 14:57 , Hank Nussbacher wrote: > Has anyone tested how many writes are going on to the ATLAS thumb > drive? Perhaps with all the failures within a year of start, perhaps > too many writes are taking place? We have no clear idea why they fail. It seems that time to failure is highly variable. From gert at space.net Fri May 20 19:03:58 2016 From: gert at space.net (Gert Doering) Date: Fri, 20 May 2016 19:03:58 +0200 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: <573F1AE7.3050902@ripe.net> References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> <573F1AE7.3050902@ripe.net> Message-ID: <20160520170358.GO1755@Space.Net> Hi, On Fri, May 20, 2016 at 04:10:47PM +0200, Philip Homburg wrote: > We have no clear idea why they fail. It seems that time to failure is > highly variable. Can you correlate tests-until-failure or data-written-until-failure? One of mine has failed at least two times now, and it could be that people just *love* to run tests from 3320... My gen 1 probe in 5539 has never had *any* issues. 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: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From remaker at gmail.com Fri May 20 21:08:08 2016 From: remaker at gmail.com (Phillip Remaker) Date: Fri, 20 May 2016 12:08:08 -0700 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: <20160520170358.GO1755@Space.Net> References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> <573F1AE7.3050902@ripe.net> <20160520170358.GO1755@Space.Net> Message-ID: So I have a few theories. I have now had 3 different USB sticks fail on me: Two Sandisk 4GB SDCZ33 and one cheap generic 8GB replacement. The power draw of the TP-Link system + USB is probably more than the opportunistic USB ports they get plugged in to. An underpowered probe runs great MOST of the time, but a flash bit write is probably the highest power strain and Flash can get really unhappy with power interrupts, based on this SSD research: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf I usually use a 500mA or 800mA supply, or tap a nearby router USB port in that range. I suspect the system may demand 1200mA or more. When most flash sticks get errored out enough, they permanently fail into a read only mode, or become fully unreadable. Read-only mode can be reset on some models, but it is not recommended by the vendor. At least one of the failed SANdisk units I had was stuck in a read-only mode. Also, probes may be subjected to ungraceful power down situations, depending on where they are stationed. That can also be a flash drive killer. I don't think we are hitting the write limits of the sticks. I suspect the units are often in underpowered or ungraceful pwoer-down situations, or the USB flash itself is not responding gracefully to poweroff situations. I don't suppose RIPE buys enough USB sticks to get to talk to engineers at SanDISK? I know the newer Raspberry Pi will report when it is in an underpowered situation. Can the TP-Link detect and warn when underpowered? What is the minimum power recommended for TP-Link + USB? Also, are there any USB sticks that have lower power needs and are more robust in low power IoT situations? Is anyone trying to post-mortem the failed sticks? On Fri, May 20, 2016 at 10:03 AM, Gert Doering wrote: > Hi, > > On Fri, May 20, 2016 at 04:10:47PM +0200, Philip Homburg wrote: > > We have no clear idea why they fail. It seems that time to failure is > > highly variable. > > Can you correlate tests-until-failure or data-written-until-failure? > > One of mine has failed at least two times now, and it could be that > people just *love* to run tests from 3320... > > My gen 1 probe in 5539 has never had *any* issues. > > 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 -------------- An HTML attachment was scrubbed... URL: From gboonie at gmail.com Fri May 20 22:13:04 2016 From: gboonie at gmail.com (gboonie) Date: Fri, 20 May 2016 22:13:04 +0200 Subject: [atlas] Probe is down but does send DNS according tot SOS history Message-ID: <41937f94-8605-5c06-feec-f7f79f5a4b9e@gmail.com> Hi, How can it be that the status of a probe is down while I see current DNS requests in the SOS list without any remarks in the 'info' column? Even the power-up time is increasing. If the probe can send DNS requests, why does it not have some mechanism to recover? Seem not too hard to make it reboot if it's status is down. Thanks, Dave From gboonie at gmail.com Sat May 21 08:28:46 2016 From: gboonie at gmail.com (gboonie) Date: Sat, 21 May 2016 08:28:46 +0200 Subject: [atlas] Probe is down but does send DNS according tot SOS history In-Reply-To: References: <41937f94-8605-5c06-feec-f7f79f5a4b9e@gmail.com> Message-ID: No. Everything seemed normal except that it was down. All tags like "IPv4 works" etc. were there. The only thing was that the status was down. So I pulled the power, pulled USB, replaced the power. Went to brush my teeth and came back to replace USB and went to bed around 23:30 (21:30UTC) A few hours (!) later the probe came back to live. The power for the probe comes from the modem. That might be a possible cause, I'm thinking. Could the developers please see if the probe can indicate power shortage? Could it get some recovering mechanism built in? Op 21-5-2016 om 01:14 schreef Phillip Remaker: > Does it have the "Hardware Problem Suspected" tag? It may have a > failing USB sick and can only get up far enough to send SOS messages. > > On Fri, May 20, 2016 at 1:13 PM, gboonie > wrote: > > Hi, > > How can it be that the status of a probe is down while I see > current DNS requests in the SOS list without any remarks in the > 'info' column? Even the power-up time is increasing. > > If the probe can send DNS requests, why does it not have some > mechanism to recover? Seem not too hard to make it reboot if it's > status is down. > > Thanks, > Dave > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: obdkngjjnkfocfpf.png Type: image/png Size: 27402 bytes Desc: not available URL: From GeertJan.deGroot at xs4all.nl Sat May 21 11:14:42 2016 From: GeertJan.deGroot at xs4all.nl (Geert Jan de Groot) Date: Sat, 21 May 2016 11:14:42 +0200 Subject: [atlas] USB drive issues In-Reply-To: References: Message-ID: <58baa015-ddb1-24ac-4820-b3407a57aac0@xs4all.nl> At the first hint of trouble, it may actually have been premature, I swapped the USB drive on my probe with a brandname replacement. Note that there is a lot of poor quality stuff, especially in "giveaway" drives, and the fact that the disc is encrypted of course does not help heuristics in the USB drive controller to lengthen the drive life. The replacement was painless: power down, insert blank disk, powerup, did the dishes, when I was done the probe was done initializing and everything was working fine. I've added "replaced-broken-sandisk-usb-stick" to the probe. Perhaps this is a useful heuristic to monitor how prevalent the problem really is. Geert Jan From colinj at mx5.org.uk Sat May 21 12:00:29 2016 From: colinj at mx5.org.uk (Colin Johnston) Date: Sat, 21 May 2016 11:00:29 +0100 Subject: [atlas] USB drive issues In-Reply-To: <58baa015-ddb1-24ac-4820-b3407a57aac0@xs4all.nl> References: <58baa015-ddb1-24ac-4820-b3407a57aac0@xs4all.nl> Message-ID: <6AE7AFDA-9AF0-4D20-9B04-3BE0AC520157@mx5.org.uk> as a probe 1 user we dont see these problems as not memory card based but i do use usb power from homehub. if there is a spare probe3 is avail i am happy to test usb power use colin Sent from my iPhone > On 21 May 2016, at 10:14, Geert Jan de Groot wrote: > > At the first hint of trouble, it may actually have been premature, > I swapped the USB drive on my probe with a brandname replacement. > Note that there is a lot of poor quality stuff, especially in > "giveaway" drives, and the fact that the disc is encrypted > of course does not help heuristics in the USB drive controller > to lengthen the drive life. > > The replacement was painless: power down, insert blank disk, > powerup, did the dishes, when I was done the probe was done > initializing and everything was working fine. > > I've added "replaced-broken-sandisk-usb-stick" to the probe. > Perhaps this is a useful heuristic to monitor how prevalent > the problem really is. > > Geert Jan > From hank at efes.iucc.ac.il Sat May 21 21:32:28 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 21 May 2016 22:32:28 +0300 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> <573F1AE7.3050902@ripe.net> <20160520170358.GO1755@Space.Net> Message-ID: <7b6761d5-f534-0d9c-85dc-7351476b3b0d@efes.iucc.ac.il> On 20/05/2016 22:08, Phillip Remaker wrote: > > When most flash sticks get errored out enough, they permanently fail > into a read only mode, or become fully unreadable. Read-only mode can > be reset on some models, but it is not recommended by the vendor. At > least one of the failed SANdisk units I had was stuck in a read-only mode. > > Also, probes may be subjected to ungraceful power down situations, > depending on where they are stationed. That can also be a flash drive > killer. > > I don't think we are hitting the write limits of the sticks. I suspect > the units are often in underpowered or ungraceful pwoer-down > situations, or the USB flash itself is not responding gracefully to > poweroff situations. > > I don't suppose RIPE buys enough USB sticks to get to talk to > engineers at SanDISK? > Sandisk R&D is located in Israel: http://www.globes.co.il/en/article-sandisk-acquisition-affects-650-israeli-employees-1001075338 I could probably arrange a meeting with the technical staff there provided there is a clear document detailing the issue. Maybe RIPE ATLAS technical staff would like to come to a meeting? Regards, Hank From mhi at ionescu.de Sat May 21 22:32:25 2016 From: mhi at ionescu.de (Michael Ionescu) Date: Sat, 21 May 2016 22:32:25 +0200 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> <573F1AE7.3050902@ripe.net> <20160520170358.GO1755@Space.Net> Message-ID: <5EC485D6-9CBD-4F20-96E6-8F09C5E5CACE@ionescu.de> On May 20, 2016 9:08:08 PM GMT+02:00, Phillip Remaker wrote: >I don't suppose RIPE buys enough USB sticks to get to talk to engineers >at SanDISK? I just had a Verbatim drive originally supplied with the probe go read-only, so I would say RIPE is not procuring only SanDISK. -- From mhi at ionescu.de Sat May 21 22:39:51 2016 From: mhi at ionescu.de (Michael Ionescu) Date: Sat, 21 May 2016 22:39:51 +0200 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: <49499842-92AC-40BD-98DC-E023E69B0E16@ionescu.de> References: <49499842-92AC-40BD-98DC-E023E69B0E16@ionescu.de> Message-ID: <3224DF5E-4111-4D19-B9FB-F639EC9E655E@ionescu.de> On May 20, 2016 3:58:06 PM GMT+02:00, Philip Homburg wrote: >No, the probe actually runs from the USB stick. The internal 4MB flash >is just enough to initialize the USB stick in a secure way. And even >that is already tricky. Could you perhaps write some statistical data regarding drive usage to a cleartext partition that could be evaluated by the hoster once the probe is in limbo? -- From mhi at ionescu.de Sun May 22 05:21:59 2016 From: mhi at ionescu.de (Michael Ionescu) Date: Sun, 22 May 2016 05:21:59 +0200 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> <573F1AE7.3050902@ripe.net> <20160520170358.GO1755@Space.Net> <5EC485D6-9CBD-4F20-96E6-8F09C5E5CACE@ionescu.de> Message-ID: It was powered through the dedicated wall plug included with the probe. On May 22, 2016 12:03:39 AM GMT+02:00, Phillip Remaker wrote: >How was the drive powered? Dedicated supply, or a port on a router? > >On Sat, May 21, 2016 at 1:32 PM, Michael Ionescu >wrote: > >> On May 20, 2016 9:08:08 PM GMT+02:00, Phillip Remaker > >> wrote: >> >I don't suppose RIPE buys enough USB sticks to get to talk to >engineers >> >at SanDISK? >> >> I just had a Verbatim drive originally supplied with the probe go >> read-only, so I would say RIPE is not procuring only SanDISK. From philip.homburg at ripe.net Mon May 23 09:27:09 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 23 May 2016 09:27:09 +0200 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: <7b6761d5-f534-0d9c-85dc-7351476b3b0d@efes.iucc.ac.il> References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> <573F1AE7.3050902@ripe.net> <20160520170358.GO1755@Space.Net> <7b6761d5-f534-0d9c-85dc-7351476b3b0d@efes.iucc.ac.il> Message-ID: <5742B0CD.8020603@ripe.net> On 2016/05/21 21:32 , Hank Nussbacher wrote: > On 20/05/2016 22:08, Phillip Remaker wrote: >> I don't suppose RIPE buys enough USB sticks to get to talk to >> engineers at SanDISK? >> > Sandisk R&D is located in Israel: > http://www.globes.co.il/en/article-sandisk-acquisition-affects-650-israeli-employees-1001075338 > I could probably arrange a meeting with the technical staff there > provided there is a clear document detailing the issue. > Maybe RIPE ATLAS technical staff would like to come to a meeting? We switched from SanDisk to Verbatim because the failure rate of the SanDisk was too high. Unfortunately, the log files that contain details about the USB sticks are archived in a way that makes them hard to access. But we will try to analyze those logs soon to see what we can get out of them. Independent of that, it would be nice if we could figure out a way to induce failures (instead of having to way for probes in the field to end up with a corrupt filesystem) and to figure out what causes those failures. One thing we currently wonder is if a marginal power supply (as seen from the USB stick) would cause corruption or not. Philip From v.bajpai at jacobs-university.de Mon May 23 11:21:24 2016 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Mon, 23 May 2016 09:21:24 +0000 Subject: [atlas] v4 versus v6 -- who connects faster? Message-ID: <519FE7FA-122B-4BA8-8797-20588025240D@jacobs-university.de> Hello, -- sorry for cross-posting Here [a] is a toy v6 service I came up with during the RIPE Atlas hackathon over this weekend. Thought I share this along: [a] http://goo.gl/hbzbwD You enter a dual-stacked website (ALEXA top 10K) and it shows you the difference in TCP connect times over v4 and v6 as seen by all dual-stacked RIPE Atlas probes (~1.3K probes). You can also filter the visualisation from a specific origin-AS. This additional filter can be useful to view performance towards a website from a specific origin-AS (say DTAG). Disclaimer: This is an outcome of a 1.5d long hackathon project. As such, the codebase is possibly inundated with bugs. Please don?t see it as a production service :-) Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =================================== From joe.provo at gmail.com Fri May 20 22:53:26 2016 From: joe.provo at gmail.com (Joe Provo) Date: Fri, 20 May 2016 16:53:26 -0400 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> <573F1AE7.3050902@ripe.net> <20160520170358.GO1755@Space.Net> Message-ID: Fwiw, I always power directly from an outlet, never tributary on the USB. I've yet to have such fails, so my anecdata aligns with the underpower theory. On May 20, 2016 15:08, "Phillip Remaker" wrote: So I have a few theories. I have now had 3 different USB sticks fail on me: Two Sandisk 4GB SDCZ33 and one cheap generic 8GB replacement. The power draw of the TP-Link system + USB is probably more than the opportunistic USB ports they get plugged in to. An underpowered probe runs great MOST of the time, but a flash bit write is probably the highest power strain and Flash can get really unhappy with power interrupts, based on this SSD research: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf I usually use a 500mA or 800mA supply, or tap a nearby router USB port in that range. I suspect the system may demand 1200mA or more. When most flash sticks get errored out enough, they permanently fail into a read only mode, or become fully unreadable. Read-only mode can be reset on some models, but it is not recommended by the vendor. At least one of the failed SANdisk units I had was stuck in a read-only mode. Also, probes may be subjected to ungraceful power down situations, depending on where they are stationed. That can also be a flash drive killer. I don't think we are hitting the write limits of the sticks. I suspect the units are often in underpowered or ungraceful pwoer-down situations, or the USB flash itself is not responding gracefully to poweroff situations. I don't suppose RIPE buys enough USB sticks to get to talk to engineers at SanDISK? I know the newer Raspberry Pi will report when it is in an underpowered situation. Can the TP-Link detect and warn when underpowered? What is the minimum power recommended for TP-Link + USB? Also, are there any USB sticks that have lower power needs and are more robust in low power IoT situations? Is anyone trying to post-mortem the failed sticks? On Fri, May 20, 2016 at 10:03 AM, Gert Doering wrote: > Hi, > > On Fri, May 20, 2016 at 04:10:47PM +0200, Philip Homburg wrote: > > We have no clear idea why they fail. It seems that time to failure is > > highly variable. > > Can you correlate tests-until-failure or data-written-until-failure? > > One of mine has failed at least two times now, and it could be that > people just *love* to run tests from 3320... > > My gen 1 probe in 5539 has never had *any* issues. > > 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 -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Mon May 23 13:21:31 2016 From: mir at ripe.net (=?iso-8859-1?q?Mirjam_K=FChne?=) Date: Mon, 23 May 2016 13:21:31 +0200 Subject: [atlas] New on RIPE Labs: New RIPE Atlas APIs and User Manuals Message-ID: Dear colleagues, We've updated the RIPE Atlas APIs - and there's a comprehensive new manual to explain how to use them. As a result, the current (version 1) APIs are still available for now, but will be deprecated by the end of the year. Please find more information on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/new-ripe-atlas-apis?pk_campaign=labs&pk_kwd=list-atlas Kind regards, Mirjam Kuehne RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From hank at efes.iucc.ac.il Mon May 23 13:31:57 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 23 May 2016 14:31:57 +0300 Subject: [atlas] Documentation In-Reply-To: <519FE7FA-122B-4BA8-8797-20588025240D@jacobs-university.de> References: <519FE7FA-122B-4BA8-8797-20588025240D@jacobs-university.de> Message-ID: Just saw announced the following: > RIPE ATLAS > We?ve updated the RIPE Atlas APIs and created a comprehensive user > manual that explains everything you need to know about how to use them: > https://labs.ripe.net/Members/suzanne_taylor_muzzin/new-ripe-atlas-apis which leads me to: https://atlas.ripe.net/docs/api/v2/manual/ Would it be possible to create a single file PDF of the API manual? Thanks, Hank From woeber at cc.univie.ac.at Mon May 23 14:41:51 2016 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Mon, 23 May 2016 14:41:51 +0200 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> Message-ID: <5742FA8F.1080202@cc.univie.ac.at> [...] > Has anyone tested how many writes are going on to the ATLAS thumb > drive? Perhaps with all the failures within a year of start, perhaps > too many writes are taking place? I know that a very small number of probes is not a valid basis for statistics, but there wasn't a USB drive failure yet for the long-term, always-on probe. But they are powered with dedicated, stable power sources. Thus I tend to lean more towards the explanation involving level or stability of power, rather than # of writes. FWIW, Wilfried > Regards, > Hank From v.bajpai at jacobs-university.de Mon May 23 14:42:50 2016 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Mon, 23 May 2016 12:42:50 +0000 Subject: [atlas] Documentation In-Reply-To: References: <519FE7FA-122B-4BA8-8797-20588025240D@jacobs-university.de> Message-ID: <2D29883B-50B1-4893-85A4-A1B3ED0C6BD0@jacobs-university.de> > On 23 May 2016, at 13:31, Hank Nussbacher wrote: > > Just saw announced the following: > >> RIPE ATLAS >> We?ve updated the RIPE Atlas APIs and created a comprehensive user >> manual that explains everything you need to know about how to use them: >> https://labs.ripe.net/Members/suzanne_taylor_muzzin/new-ripe-atlas-apis >> which leads me to: >> https://atlas.ripe.net/docs/api/v2/manual/ > > Would it be possible to create a single file PDF of the API manual? +1 -- current documentation is heavily paged! > Thanks, > Hank Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =================================== From bruno.pagani at ens-lyon.org Mon May 23 14:48:19 2016 From: bruno.pagani at ens-lyon.org (Bruno Pagani) Date: Mon, 23 May 2016 14:48:19 +0200 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: <5742FA8F.1080202@cc.univie.ac.at> References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> <5742FA8F.1080202@cc.univie.ac.at> Message-ID: Le 23/05/2016 ? 14:41, Wilfried Woeber a ?crit : > [...] >> Has anyone tested how many writes are going on to the ATLAS thumb >> drive? Perhaps with all the failures within a year of start, perhaps >> too many writes are taking place? > I know that a very small number of probes is not a valid basis for statistics, > but there wasn't a USB drive failure yet for the long-term, always-on probe. > > But they are powered with dedicated, stable power sources. > Thus I tend to lean more towards the explanation involving level or stability > of power, rather than # of writes. > > FWIW, > Wilfried > >> Regards, >> Hank FWIW, my failed #12033 probe was powered using only 1 usb port from my ISP provided router. I?ve plugged the replacement one on a 2+1?A dedicated power supply. So while that second one hasn?t been around long enough to be relevant, the first one fall in the low power level issue range. Bruno -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From james.cutler at consultant.com Mon May 23 15:35:45 2016 From: james.cutler at consultant.com (James R Cutler) Date: Mon, 23 May 2016 09:35:45 -0400 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: <5742FA8F.1080202@cc.univie.ac.at> References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> <5742FA8F.1080202@cc.univie.ac.at> Message-ID: <588A5C79-9AA1-4B10-A1AF-BC9277CF1EBD@consultant.com> > On May 23, 2016, at 8:41 AM, Wilfried Woeber wrote: > > [...] >> Has anyone tested how many writes are going on to the ATLAS thumb >> drive? Perhaps with all the failures within a year of start, perhaps >> too many writes are taking place? > > I know that a very small number of probes is not a valid basis for statistics, > but there wasn't a USB drive failure yet for the long-term, always-on probe. > > But they are powered with dedicated, stable power sources. > Thus I tend to lean more towards the explanation involving level or stability > of power, rather than # of writes. > > FWIW, > Wilfried > >> Regards, >> Hank > Stable power, as from a UPS, also isolates the probe from power glitches which may cause rebooting of the probe, thus adding to the write count. Not to mention corruption from power failure during writes. Opinion: If the device/system/operation is at all important, use of a UPS is effectively mandatory. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 872 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jdenhertog at ripe.net Mon May 23 16:15:30 2016 From: jdenhertog at ripe.net (Jasper den Hertog) Date: Mon, 23 May 2016 16:15:30 +0200 Subject: [atlas] Documentation In-Reply-To: <2D29883B-50B1-4893-85A4-A1B3ED0C6BD0@jacobs-university.de> References: <519FE7FA-122B-4BA8-8797-20588025240D@jacobs-university.de> <2D29883B-50B1-4893-85A4-A1B3ED0C6BD0@jacobs-university.de> Message-ID: <764E7F9E-5882-4B0A-8BAD-7EAFCD44979D@ripe.net> > On 23 May 2016, at 14:42, Bajpai, Vaibhav wrote: >> Would it be possible to create a single file PDF of the API manual? That is certainly possible. I will put up a link to it either today or tomorrow. I?ll post you when done. greetings, Jasper RIPE Atlas Software Engineer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2619 bytes Desc: not available URL: From jdenhertog at ripe.net Mon May 23 17:53:34 2016 From: jdenhertog at ripe.net (Jasper den Hertog) Date: Mon, 23 May 2016 17:53:34 +0200 Subject: [atlas] Documentation In-Reply-To: <764E7F9E-5882-4B0A-8BAD-7EAFCD44979D@ripe.net> References: <519FE7FA-122B-4BA8-8797-20588025240D@jacobs-university.de> <2D29883B-50B1-4893-85A4-A1B3ED0C6BD0@jacobs-university.de> <764E7F9E-5882-4B0A-8BAD-7EAFCD44979D@ripe.net> Message-ID: <9003CE4D-DF3B-45A7-8B3E-B6856E20D51B@ripe.net> And here it is: https://atlas.ripe.net/docs/api/v2/manual/pdf/ripe_atlas_api_V2_manual.pdf The link is also included in the introduction page of the manual, I will add a link to the Documentation page on atlas.ripe.net next week. greetings, Jasper > On 23 May 2016, at 16:15, Jasper den Hertog wrote: > > >> On 23 May 2016, at 14:42, Bajpai, Vaibhav wrote: >>> Would it be possible to create a single file PDF of the API manual? > > That is certainly possible. I will put up a link to it either today or tomorrow. > I?ll post you when done. > > greetings, > > Jasper > RIPE Atlas Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2619 bytes Desc: not available URL: From hank at efes.iucc.ac.il Mon May 23 18:08:14 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 23 May 2016 19:08:14 +0300 Subject: [atlas] Documentation In-Reply-To: <9003CE4D-DF3B-45A7-8B3E-B6856E20D51B@ripe.net> References: <519FE7FA-122B-4BA8-8797-20588025240D@jacobs-university.de> <2D29883B-50B1-4893-85A4-A1B3ED0C6BD0@jacobs-university.de> <764E7F9E-5882-4B0A-8BAD-7EAFCD44979D@ripe.net> <9003CE4D-DF3B-45A7-8B3E-B6856E20D51B@ripe.net> Message-ID: On 23/05/2016 18:53, Jasper den Hertog wrote: Excellent! Thanks, Hank > And here it is: > > https://atlas.ripe.net/docs/api/v2/manual/pdf/ripe_atlas_api_V2_manual.pdf > > The link is also included in the introduction page of the manual, > > I will add a link to the Documentation page on atlas.ripe.net > next week. > > greetings, > > Jasper > >> On 23 May 2016, at 16:15, Jasper den Hertog > > wrote: >> >> >>> On 23 May 2016, at 14:42, Bajpai, Vaibhav >>> >> > wrote: >>>> Would it be possible to create a single file PDF of the API manual? >> >> That is certainly possible. I will put up a link to it either today >> or tomorrow. >> I?ll post you when done. >> >> greetings, >> >> Jasper >> RIPE Atlas Software Engineer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danny at danysek.cz Tue May 24 09:15:39 2016 From: danny at danysek.cz (Daniel Suchy) Date: Tue, 24 May 2016 09:15:39 +0200 Subject: [atlas] USB drive more harmful than helpful? In-Reply-To: <588A5C79-9AA1-4B10-A1AF-BC9277CF1EBD@consultant.com> References: <4425E22A-E930-4A20-8860-8AE459106A57@ionescu.de> <5742FA8F.1080202@cc.univie.ac.at> <588A5C79-9AA1-4B10-A1AF-BC9277CF1EBD@consultant.com> Message-ID: It doesn't help, when we're talking about Atlas probes. I have one probe, where external flash died twice, even it's placed in datacenter with UPS-protected power. On 23.05.16 15:35, "ripe-atlas on behalf of James R Cutler" wrote: Stable power, as from a UPS, also isolates the probe from power glitches which may cause rebooting of the probe, thus adding to the write count. Not to mention corruption from power failure during writes. Opinion: If the device/system/operation is at all important, use of a UPS is effectively mandatory. -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.bajpai at jacobs-university.de Tue May 24 10:31:19 2016 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Tue, 24 May 2016 08:31:19 +0000 Subject: [atlas] Documentation In-Reply-To: <9003CE4D-DF3B-45A7-8B3E-B6856E20D51B@ripe.net> References: <519FE7FA-122B-4BA8-8797-20588025240D@jacobs-university.de> <2D29883B-50B1-4893-85A4-A1B3ED0C6BD0@jacobs-university.de> <764E7F9E-5882-4B0A-8BAD-7EAFCD44979D@ripe.net> <9003CE4D-DF3B-45A7-8B3E-B6856E20D51B@ripe.net> Message-ID: > On 23 May 2016, at 17:53, Jasper den Hertog wrote: > > And here it is: > > https://atlas.ripe.net/docs/api/v2/manual/pdf/ripe_atlas_api_V2_manual.pdf > > The link is also included in the introduction page of the manual, > I will add a link to the Documentation page on atlas.ripe.net next week. Thanks for a quick action :-) > greetings, > Jasper Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From astrikos at ripe.net Wed May 25 13:53:52 2016 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 25 May 2016 13:53:52 +0200 Subject: [atlas] =?utf-8?q?Update_on_problem_with_probes=E2=80=99_USB_stic?= =?utf-8?q?ks?= Message-ID: Hi all, We want to let you know that we have seen the active conversations about the USB sticks and the problems they?re causing for some RIPE Atlas probes. We are aware of these issues, and are taking steps to ensure this doesn?t become a real problem for the RIPE Atlas system. We?ve just published a RIPE Labs article that explains the preliminary analysis of our logs we?ve begun to investigate this issue. In the coming weeks, we will make sure we analyse all the logs we have in order to try to find a possible solution. We will keep you posted with any updates we have through this article. https://labs.ripe.net/Members/philip_homburg/a-visual-impression-of-probe-lifetimes We apologise for the inconvenience this is causing for some of our users. Thank you for continuing to be a part of RIPE Atlas. Regards, Andreas Strikos (on behalf of the RIPE Atlas team) From hank at efes.iucc.ac.il Thu May 26 18:50:50 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 26 May 2016 19:50:50 +0300 Subject: [atlas] Hackathon code & presentations? Message-ID: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-interface-hackathon Any code or presentations to share? Is the code available on Github yet? Thanks, Hank From nick at inex.ie Thu May 26 18:59:50 2016 From: nick at inex.ie (Nick Hilliard) Date: Thu, 26 May 2016 17:59:50 +0100 Subject: [atlas] Hackathon code & presentations? In-Reply-To: References: Message-ID: <57472B86.9000902@inex.ie> Hank Nussbacher wrote: > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-interface-hackathon > Any code or presentations to share? > Is the code available on Github yet? Barry O'Donovan wrote the Asymmetric Routing Detector as part of this: https://github.com/inex/ixp-as Nick From pelsser at unistra.fr Thu May 26 21:14:26 2016 From: pelsser at unistra.fr (Cristel Pelsser) Date: Thu, 26 May 2016 21:14:26 +0200 Subject: [atlas] Hackathon code & presentations? In-Reply-To: References: Message-ID: <429C0F83-DEC5-4E4C-AF92-138557F872DA@unistra.fr> Here is the current code of the tartiflette project. https://github.com/4a616d6573205265696c6c79/tartiflette > On May 26, 2016, at 6:50 PM, Hank Nussbacher wrote: > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-interface-hackathon > Any code or presentations to share? > Is the code available on Github yet? > > Thanks, > Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From BECHA at ripe.net Fri May 27 10:08:28 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 27 May 2016 10:08:28 +0200 Subject: [atlas] Hackathon code & presentations? In-Reply-To: References: Message-ID: <5748007C.4070502@ripe.net> Hi Hank, On 26/05/16 18:50, Hank Nussbacher wrote: > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-interface-hackathon > Any code or presentations to share? > Is the code available on Github yet? Some of the links are at the usual place on Github: https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib/blob/master/README.md I'm a bit slow in publishing all the results (presentations, photos, more links to code) since I'm still at RIPE72, we'll be getting that article published soon. Thanks, Vesna From hank at efes.iucc.ac.il Sat May 28 21:46:24 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 28 May 2016 22:46:24 +0300 Subject: [atlas] Hackathon code & presentations? In-Reply-To: <5748007C.4070502@ripe.net> References: <5748007C.4070502@ripe.net> Message-ID: <4d763621-95d5-f650-6af9-859fa3a2a9ef@efes.iucc.ac.il> On 27/05/2016 11:08, Vesna Manojlovic wrote: > Hi Hank, > > On 26/05/16 18:50, Hank Nussbacher wrote: >> https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-interface-hackathon >> >> Any code or presentations to share? >> Is the code available on Github yet? > > Some of the links are at the usual place on Github: > > https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib/blob/master/README.md > The "usual" place on Github was unknown to me and I was unable to find it in the atlas.ripe.net tree. Perhaps a link could be added under https://atlas.ripe.net/get-involved/community/ to the Github repository? Thanks, Hank > > I'm a bit slow in publishing all the results (presentations, photos, > more links to code) since I'm still at RIPE72, we'll be getting that > article published soon. > > Thanks, > Vesna >