<div dir="ltr"><div><div><div><div>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.<br><br></div>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:<br><a href="https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf">https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf</a><br><br></div><div>I usually use a 500mA or 800mA supply, or tap a nearby router USB port in that range. <br>I suspect the system may demand 1200mA or more.<br></div><div><br></div>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.<br><br></div><div>Also, probes may be subjected to ungraceful power down situations, depending on where they are stationed. That can also be a flash drive killer.<br></div><div><br></div>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. <br><br></div>I don't suppose RIPE buys enough USB sticks to get to talk to engineers at SanDISK?<br><div><div><div><br></div><div>I know the newer Raspberry Pi will report when it is in an underpowered situation. Can the TP-Link detect and warn when underpowered?  <br><br></div><div>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?<br><br></div><div>Is anyone trying to post-mortem the failed sticks?<br></div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 20, 2016 at 10:03 AM, Gert Doering <span dir="ltr"><<a href="mailto:gert@space.net" target="_blank">gert@space.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<span><br>
On Fri, May 20, 2016 at 04:10:47PM +0200, Philip Homburg wrote:<br>
> We have no clear idea why they fail. It seems that time to failure is<br>
> highly variable.<br>
<br>
</span>Can you correlate tests-until-failure or data-written-until-failure?<br>
<br>
One of mine has failed at least two times now, and it could be that<br>
people just *love* to run tests from 3320...<br>
<br>
My gen 1 probe in 5539 has never had *any* issues.<br>
<div><div><br>
gert<br>
--<br>
have you enabled IPv6 on something today...?<br>
<br>
SpaceNet AG                        Vorstand: Sebastian v. Bomhard<br>
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann<br>
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)<br>
Tel: <a href="tel:%2B49%20%280%2989%2F32356-444" value="+498932356444" target="_blank">+49 (0)89/32356-444</a>           USt-IdNr.: DE813185279<br>
</div></div></blockquote></div><br></div></div></div></div></div></div></div>