- ripe-atlas - mailman.ripe.net

USB drive more harmful than helpful?
by Michael Ionescu 24 May '16

24 May '16

>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

10 14

New on RIPE Labs: New RIPE Atlas APIs and User Manuals
by Mirjam Kühne 23 May '16

23 May '16

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_… Kind regards, Mirjam Kuehne RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Re: [atlas] USB drive more harmful than helpful?
by Michael Ionescu 22 May '16

22 May '16

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 <remaker(a)gmail.com> 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 <mhi(a)ionescu.de> >wrote: > >> On May 20, 2016 9:08:08 PM GMT+02:00, Phillip Remaker ><remaker(a)gmail.com> >> 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.

1 0

Re: [atlas] USB drive more harmful than helpful?
by Michael Ionescu 21 May '16

21 May '16

On May 20, 2016 3:58:06 PM GMT+02:00, Philip Homburg <philip.homburg(a)ripe.net> 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? --

1 0

Re: [atlas] USB drive issues
by Geert Jan de Groot 21 May '16

21 May '16

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

2 1

Re: [atlas] Probe is down but does send DNS according tot SOS history
by gboonie 21 May '16

21 May '16

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 <gboonie(a)gmail.com > <mailto:gboonie@gmail.com>> 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 > > > > >

1 0

Re: [atlas] USB drive more harmful than helpful?
by Joe Provo 20 May '16

20 May '16

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" <remaker(a)gmail.com> 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 <gert(a)space.net> 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 >

1 0

Probe is down but does send DNS according tot SOS history
by gboonie 20 May '16

20 May '16

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

1 0

New on RIPE Labs: There Is Gold in This Stream - Sifting Through Used RIPE Atlas Traceroute Results
by Mirjam Kühne 20 May '16

20 May '16

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=… Kind regards, Mirjam Kuehne RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Replacing flash key
by Marat Khalili 20 May '16

20 May '16

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

4 9