[retrocryptid]

I know that you didn't ask, but my $0.02 is that yes, RasPi's are unreliable. If you use one for as an unattended remote server, it will do you well to include a hardware watchdog that power cycles the device after it hangs. But modern NUCs seem to take MINUTES to boot the BIOS.

I had been using various BeagleBones and found them more reliable than RasPi's and faster to boot than the NUCs in the office.

But depending on the availability of a TI part is the road to perdition, so maybe I'm just using the wrong NUC models.

[magicalhippo]

> I know that you didn't ask, but my $0.02 is that yes, RasPi's are unreliable.

I've been using RPis and "clones" for internal services for years, and there's hardly any fuzz with them at all. At most a power cycle once a year.

They've endured house losing power multiple times, I've yet to swap SD-card on any of them, they just keep chugging.

But sure, I wouldn't trust my life to one. I just find it odd that people say they're highly unreliable while all of mine just work.

[retrocryptid]

Happy that yours works well. Many problems don't show up until you hit larger numbers.

We deployed over 1k RasPi's for a particular customer. We averaged about five reboots per day. On top of that I had to deal with the RasPi Organization's insistence that they were not an ODM. Though these were the RasPi B's and RasPi2 B+'s. I'm sure the reliability has gotten better over the years.

I'm not a big TI fan, but everything I needed I got in a BeagleBone: they're more reliable than RasPi's, you can actually get the firmware source code and they have a "normal" returns process.

I don't have the data for the BBB based cube-sats running Kubos (which was the project after the RasPi project) and there were less than 50 deployed, but I've never heard of any of them rebooting themselves unless the ground told them to do so or there was a battery failure.

[olabyne]

Raspi's are stable if you respect 2 things :

- avoid writes to sd card too much (log2ram mitigates this, alpine in read-only solves this)

- plenty of power (the recent 3 and 4 have huge sipkes of current draw !)

Do you know the reason for your reboots ? Also before the 3+, the die have no RF shield. The B and 2 B+ are exposed if you don't use a metal case with a seperation from the PSU.

[magicalhippo]

> plenty of power

Actually this is a good point I forgot about.

I had one Pi which would reboot or hang every week or so. Dismissed it for a while but then decided to troubleshoot it. I had a USB cable tester, and quickly found that the USB "charging cable" I had bought from a local shop had a 1 Ohm resistance! Threw it away and replaced it with a good one and never had an issue again.

[retrocryptid]

Yes. RasPis are stable except when they're not.

[magicalhippo]

Ok 1k is certainly a sizable fleet, and I only got 3B's or newer.

Nobody imports BeagleBone here so have to get it through DigiKey or similar, which means prices are way higher.

[appleiigs]

> We deployed over 1k RasPi's for a particular customer

Is that the proper tool for the job?? I just read an article saying "Unpopular Opinion: Don't Use a Raspberry Pi for That" (https://news.ycombinator.com/item?id=35260322)

[outworlder]

... what were they doing with 1k Pi's

Please tell me they were using the GPIO pins for something.

[retrocryptid]

Of course. GPIO is the simplest way to get a blinky light.

Seriously though, we used a GPIO pin to stroke the watchdog.

[creeble]

More anecdata: my Open Sprinkler Pi has been running for many years, with only power-fail reboots (maybe once a year). It doesn’t write much to flash, but it’s never needed a reboot because it failed.

[nickthegreek]

My rPi pihole hasn't had a single hiccup for years. Multi power outages and everything. I actually thought it was going to be a way bigger hassle over time but its been smooth sailing.

[fer]

I've had about half a dozen Raspberry Pi in total (only 1 through 3), and many dozens of SBCs, and I found Raspis generally unreliable except for the Raspberry Pi 1 (model B), which is extremely slow for anything nowadays.

The longest I've had running was a The Things Network gateway on a Raspberry Pi 3: OK for 2 years, then it killed the sd card (not corruption, it just wouldn't work anywhere anymore). I set it up again and it killed the new card within a week. Again, and within a month. I gave up and it sucks because the LoRa shield is Raspberry-specific.

A Raspberry Pi 2 died just because while decoding ADS-B. SD was fine.

For the rest of the experiences, I always found some data corruption at some point. Often hanging and needing monthly reboots.

The only worse SBC (and it wasn't really an SBC) I've experienced was the Cubox i4-Pro. I eventually lost it, and I'm almost glad, weekly data corruptions and crashes, underwhelming performance and very fickle behavior overall.

Other <randomfruit> Pis have turd-tier hardware support but whatever you manage to get running tends to be reliable. Pine64 (the oldest model) is so far the only SBC I haven't seen crash, trash an SD card yet, or have FS corruptions yet.

[retrocryptid]

So what you're saying is except for the times it rebooted, it didn't reboot.

[LaputanMachine]

As long as you use a good power supply along with Ethernet instead of WiFi, Raspberry Pis are rock solid in my experience.

Regardless, I'd also recommend setting up the hardware watchdog just in case. It's saved me in the past when I overloaded my Pi with a bad cron job.

[outworlder]

> I know that you didn't ask, but my $0.02 is that yes, RasPi's are unreliable. If you use one for as an unattended remote server, it will do you well to include a hardware watchdog that power cycles the device after it hangs.

Maybe you got a bad batch. My Pis never had any problems whatsoever.

Please check logs to see if they are experiencing brownouts. Not all power supplies work, specially with a Pi4.

The thing that likes to fail a lot is SD cards. My homeassistant Pi uses a SSD(harvested from an old Chromebook) because of that.

TinyMiniMicros seem to be a better option than NUCs these days. Boot faster too.

[bsder]

People haven't been able to get an RPi for years, and yet they still won't switch to those nice Beaglebone Blacks running standard Debian in stock over there.

Shrug. At this point I see RPis as a litmus test.

[retrocryptid]

Should probably expand on this a bit. In 2014 we were involved in a project with a reasonably well-known power grid operator. They had been deploying expensive equipment to monitor the status of various devices at remote substations. They had soft requirements for uptime, which means they set a budget and got the most reliable equipment they could afford. The monitoring system was expected to work somewhere between 4 and 5 nines, but if it didn't no one was going to get fired. The equipment they had been deploying was more or less expensive overkill, offering 5 9's for about $50k per box. Multiply that by about 1600 and you get the idea for the budget. Someone in the organization hit on the idea of using redundant consumer-grade equipment and initially spec'd out some rack-mount x86 systems with beefy redundant power supplies and SSD storage. But then they heard about RasPi's and wanted to give them a try.

Should you use a Raspberry Pi for that? The best way to answer that question was to try it out. The first 20 units were built out with a beefy, though small UPS and a decent enclosure. They were deployed alongside existing systems to see if they a) worked, b) gave the same data as the expensive system and c) were reliable.

The answer was... some individual units did not hit the 4 9's reliability target. The ones that did, seemed to continue to be reliable up to at least 5 9's. But it was hard to determine which would fail without putting them in the field, waiting six months and seeing which ones hung. But the price was cheap enough that putting two in the same corner of the wiring cabinet and adding a hardware watchdog was quite affordable.

We deployed just over 1000 in this redundant configuration and it worked fine.

By this time we collected enough data to chart a MTBF histogram, essentially a chart of how many machines lasted how many days without needing a reboot. We wound up using a lot of Original RaspberryPi B+'s in 2015, which was after the RasPi 2 came out. (Purchasing at this client took a LONG time.) I often wonder if our supplier sent us boards that had been returned from other customers.

I had good experiences with BeagleBoard's in the late 2000's and this was just as the Black was coming out. We deployed another 600 with BeagleBone Blacks and got MUCH better reliability numbers. Is the BBB an intrinsically better product? I dunno. Did I just get a batch of bad RasPi's from my supplier? I dunno. Should you ever run an embedded system without a hardware watchdog? Probably not, no matter how reliable you think your system is.

But... the real problem with the RasPis was support. How do you return a RasPi? You don't. You throw it away and get a new one. Yeah. That doesn't work for a lot of people. How do you get the firmware for a RasPi in 2015? You don't. Can I get the gerbers so I can turn a few custom boards? No. I talked with RPT several times about this and their response was "we're not an ODM."

And that's PERFECTLY FINE. I never said I though RasPi's were "bad" -- I may have said "there are applications for which RasPis are not a great fit." If you need the firmware, consistent reliability or the ability to turn custom boards, you absolutely don't want to buy a raspberry pi in 2015.

Also... a lot of people are responding with "Except for the several times the system rebooted, I didn't have to reboot my RasPi," which I'm not sure I understand.