NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Status of RPi 3 (b) ?



On Fri, 6 Jan 2017, Christian Baer wrote:
Good mornin'!

:-)

Why would you do such a thing?

Just for fun. I knew I was going to make multiple mistakes, use multiple SD cards, and basically just screw around.

However, I have several other machines running it - primarily because of ZFS. ZFS is a memory hog - and a big fat one at that. This is no big deal on a server or workstation with lots of RAM, but unfortunately, the Raspi doesn't really fit into that category.

I totally agree. Most optimizations for ZFS don't even kick in unless you have 4GB of RAM or more. The OpenZFS tuning guide states that 1GB of RAM is sufficient, but more is recommended. ZFS ARC sizes with 1GB are too small for any kind of decent prefetch performance, though.

Although I haven't really measured it, I'm pretty sure that ZFS is also pretty heavy on the CPU (compared to FFS).

My experience with it on Solaris is that it depends on how you deploy the compression, deduplication, encryption, and built-in file sharing options. Load up on those, start using it heavily, and you can turn the machine into slag. That's also not to mention the checksums ZFS is constantly calculating. I can't prove it either, but I'd bet money you are right vis-a-vis FFS.

UFS/FFS with soft updates is probably a better choice for a machine like a Raspi.

Yeah, probably. That and I don't even know if they have a boot sector that'd let you put your root disk on ZFS on the ARM platform. I kinda doubt that. However, I wouldn't bet on UFS+softdeps being better than a *well tuned* ZFS rig. One could disable prefetch, lower the arc_max, and then override the TXG write_limit to force it to flush & sync a bit more and you'd probably be just fine and maybe match or beat UFS. It'd be an interesting test, actually.

This "multicolor test pattern" is the Raspi's way of telling you that it can't load the OS.

I figured it was something like that. That's better than a black screen, I guess. At least the monitor power save doesn't kick in and you can tell what happened.

You have stated the reason quite well: The Raspi3 only works with NetBSD current.

Thanks for the confirmation. My RPi v2 comes today in the mail, so either way, I'll be playing with NetBSD on some kind of Pi in the near future.

That depends. IIRC everything works fine apart from the wireless-stuff (Wifi and Bluetooth).

I heard some rumor that the OpenBSD guys have eschew Pis and focus on BeagleBones because of some binary blobs they don't want to distribute. It's always a mess with wifi and bluetooth. That and I can't keep up with who distributes what and who refuses. I think the deal with the OpenBSD crew is they don't want to be on the hook for redistributing blobs, but they'll cope with them if the machine uses them "internally". However, that whole topic gets ranty and endless once it starts. I mostly can't be bothered to care about it. I get a little "consumerish" and I figure folks like Stallman, Theo, and ESR can fight that fight elsewhere without me. I'll just plug in USB dongles as-needed.

However, I have always found using any -current OS to be extremely ball-busting.

Heh, true. However, I've had okay luck with picking a -current image for whatever weird kit I'm messing with at the time then just not updating once I find an image that works. Now *tracking* -current, oh man, yeah, that's a challenge. I don't yet have all the chops I need to track down bugs and regressions that crop up. I can code in C, but I'm not well practiced enough to find bugs before others do.

I'll grant you that NetBSD is a lot more conservative (even in -current) than FreeBSD and especially most Linux distros (which are completely bleeding edge). But even with NetBSD it can happen that after an update (which you installed because some feature was a little flaky), the system won't work anymore or you just have a bug-change. Basically, not the best choice for a production-system.

I'm just playing around, so no big deal, though I agree on the finer points you make. If I had a "production" application using Pi's I'd probably just buy two of them and keep known-good SD card images laying around. Plus, I tend to test & harden using very common hardware extensively before I put them in a position to lose money. Still, Pis are fun and definitely powerful enough for "real work" under the righ circumstances.

-Swift


Home | Main Index | Thread Index | Old Index