You might have noticed that it has been fairly quiet around here recently. That’s mainly because real life has been getting in the way quite a lot, but also because what little spare time I have has been taken up by a new project. I’m not ready to spill the beans on what that project is quite yet, but you can get a couple of fairly strong hints on what direction I’m going (!) by taking a look at the beautifully executed work of Matthias Hammer (and his daughter) on their autonomous equipment project. Note that Matthias isn’t limiting his work just to autonomous control of the tractor, but is also extending the project to automate the other agricultural equipment that he uses.
Yup, the most frequent comment on Hackaday, “You could have used a 555 for that”. Well, I did. In fact, I used a pair of 555s …but probably not the sort you’re thinking of.
A few years back (see date-code photo, below), I found these batteries in a local equivalent of the “Dollar Store”. They only came in pairs, which made them more than twice as expensive as the normal, no-name AA alkaline cells, but with that branding I had to get at least one pack.
I used them (probably in one of my PIC projects back then) and then forgot about them, until I was scrambling to find some not-quite-so-dead batteries to check an ESP01S project a couple of weeks back and found them at the back of a drawer.
I popped the DVM probes on them (unloaded, of course) and was very surprised to see a healthy 1.5v reading.
Well okay, lets fire this thing up and see what happens! What happened was that the ESP01S blue LED flashed, then …nothing. Turning one of them upside-down, the date code reminded me that it was very many moons ago that I last used them.
They certainly didn’t owe me anything, but I wondered what the voltage had gone down to under load. Having had lots of experience with these el-cheapo batteries, I wasn’t at all surprised to see that the voltage across the cell swung well into negative territory when I held down the “On” switch. What still surprised me was that the voltage swung almost straight back to that “healthy” 1.5v reading once the load was removed. Usually these cells are hard-pressed to register a no-load voltage of 0.9 ~ 1.1v in their fully depleted states.
Maybe these we’re just catching their “second wind” …or maybe they do have a 555 hidden inside them after all!
The ESP01S board wouldn’t stay powered with these batteries in the pack, so I had to hold down the “On” switch long enough to snap the photo.
No ESP01S modules were harmed in the production of this blog post, but it probably didn’t do my poor little 555s much good.
We’ve had several release candidates (at least one more than expected) of FreeBSD-13, of which I’ve tested the later ones as VMs on a 12.2-p6 host and found them to be lightweight and sprightly. So, when the final release was announced last week, I didn’t have any particular qualms about updating said 12.2 system to release 13.0. Having said that, FreeBSD makes it particularly easy to add belt-and-braces insurance to your updates nowadays, using “bectl“.
If you haven’t come across bectl before, I would heartily recommend that you check it out and read the manual page before you start any future upgrades. The “be” part of the name stands for “Boot Environment” and this extremely useful tool helps us to manage our ZFS filesystems to allow virtually risk-free changes to our root filesystem without needing to get deeply into the nitty-gritty of snapshots, rollbacks and boot menus. Yes, it only works through the magic of ZFS, but it’s just another reason why you definitely should be using this filesystem everywhere (even on your laptop).
“bectl” will enable us to quickly create a snapshot of our current root filesystem, add that snapshot to our “beastie” boot menu and, importantly, then allow us to create a completely new clone of the existing snapshot (which we can then upgrade or change in whatever way we want) and optionally make that updated filesystem available as the default boot for our machine. This means that we can install an upgrade (in my case, release 13.0) and boot it immediately, but still have the option of selecting our original root from the boot menu, if things don’t quite go to plan.
Before we start the actual upgrade, just a couple of words of warning…
As noted above, the system must be using root on ZFS.
It should be running the GENERIC kernel.
We should be starting from a recently updated version of the previous major release (ie:- 12.2-p6 if updating to 13.0).
How do we prepare our system in advance of the actual upgrade? It couldn’t be much easier. The “back-up” boot environment will be the root filesystem which we have now. We will create a new clone of this existing environment to work on during the 13.0 install (leaving the original untouched).
First, we check our current boot environment with:-
root# bectl list -D
BE Active Mountpoint Space Created
default NR / 10.2G 2020-02-16 18:02
The bectl list command shows the currently available boot environments and the “-D” argument shows the space used. The “Active” column shows an “N” for the boot environment which is in use right Now and an “R” for the boot environment which will be activated on the next Reboot. In our case, we only have one boot environment, so it is both active and selected to be used on the next reboot.
To create the cloned (work) boot environment, we do:-
The “create” is obvious. The “activate” command tells the system that we want to use the new, “13.0-RELEASE” boot environment at the next reboot. When we use the “list” command again now, we should see something similar to this:-
root# bectl list -D
BE Active Mountpoint Space Created
13.0-RELEASE R - 369K 2021-04-22 08:32
default N / 10.2G 2020-02-16 18:02
…indicating that “default” is currently in use, but that “13.0-RELEASE” will be used on the next reboot. If everything looks okay (and there were no error messages from the bectl commands), we can go ahead and reboot our system. It should boot as normal and look exactly the same as before (we haven’t actually changed anything on the filesystem yet, so we’re still running 12.2-p6). However, if we were to do another bectl list -D we’d see that the “Active” column would now show “NR” for 13.0-RELEASE and just “-” for “default”.
Do not proceed with the upgrade steps below unless you see the “NR” active status for the “13.0-RELEASE” boot environment.
Having checked that we’re using the cloned root filesystem, we can now go ahead and use that other wonderfully useful utility, freebsd-update, to start the actual upgrade process:-
root# freebsd-update -r 13.0-RELEASE
Note that “13.0-RELEASE” in this command is specifying which release we want freebsd-update to upgrade to, not where we want to install it. We simply follow the instructions which freebsd-update gives as it goes along (we will need to reboot a couple of times to complete the full upgrade process).
If everything goes as planned, after the final reboot we should have a working FreeBSD 13.0 system.
My upgrade process went smoothly; all system utilities came back up and the VMs ran with no problems. Everything looked fine …until the first, automated, weekly reboot rolled around. The machine didn’t come back up. The console was complaining that there was a fatal ZFS error with the main user-data pool (zstore00 – not the root filesystem). I had to cycle power on the system to have it reboot and, when it came back up it did indeed show a checksum error on that pool. I cleared the error and initiated a scrub and once everything was stable and had been running for a couple of days, did a manual reboot. It failed again, in the same way.
The actual error shown was;-
Solaris: WARNING: Pool zstore00 has encountered an uncorrectable I/O failure and has been suspended.
At that point the actual shutdown process hung solid and, as before, I needed to power cycle the system to have it come back up. I also tried updating the /boot/loader.conf file (as suggested in Graham Perrin’s very useful guide) and rebooted a couple of times manually, but to no avail.
Note that I had not run zfs upgrade on the pools, since this would have made it very difficult to roll back.
So, at this point I needed to get the system back up and running and decided to do that roll-back to 12.2. Here’s how you can do that…
Power cycle the machine (if you’re stuck with a hung system, as above) and once the beastie menu appears, wait a second for the additional options to appear at the bottom (it takes the boot process a moment or two to collect the boot environment listings) and then select the “Select Boot [E]nvironment…” option. You’ll get another, short menu where you can use #2 to cycle through the boot environment names until you see “default” displayed. At this point you can simply hit Enter to have the system select and boot into this saved environment.
Your system will now boot into the original 12.2-p6 root filesystem and work as before. The only minor issue that you have is that booting from the beastie menu only sets the boot environment for this one-time boot, so you must use bectl activate default to have your 12.2-p6 environment set as the permanent boot environment (if you do a bectl list -D at this point, “default” should now have “NR” showing in the Active column).
Looking a little closer at the listing you’ve just done, you’ll also notice that because we’ve actually got a complete 13.0 install on the alternate “13.0-RELEASE”, it now shows a much greater space-used than before (in my case around 12GB).
As regular readers know, I occasionally take a dive into the world of mini-pcs (especially low cost models) in my quest to get the best bang for the buck/watt. On my travels through the depths of Aliexpress this morning, I came across very reasonably priced Z8350-based system. It’s not going to blow the doors off, but I have a soft spot for these boxes, simply because they do so much for what they are.
This one is a design which is new to me, sporting more USB ports than normal, as well as both VGA and HDMI video ports. You’ll need to be careful though, as the retailer seems to be a bit confused about what hardware they’re selling …in the product “overview” they state it has 2 x USB3 and 2 x USB2, but the images clearly show 1 x USB3 and 5 x USB2 ports. The header of their advert also rather vaguely claims “support 2.5 inch HDD”, but (despite the extra height of this case compared to other models) there are no obvious SATA headers on the motherboard pictures and in the overview they only mention support of “external” disks.
They’re also a bit on the boastful side about the service they provide (hence the “giggle” in the title of this post — see image, below).
The price for the 4GB/32GB model is a modest $84.45 (plus $3 shipping to my part of the world). Although these boxes are sold as “Windows 10” machines, I certainly wouldn’t advise anyone to try running Windows on the 32GB eMMC model, as the initial download of updates will overflow the available storage space.
As I’ve mentioned before though, these machines make excellent little low-cost, low-power-usage servers for anyone doing 24/7 self hosting (I’ve even got a similar box with more than 12TB of USB disks hanging off the back as a back-up server on my home network). This version also comes with 4GB of main memory, which is 2GB more than my original Z8350 based system (which has been running 24/7 since Dec 2016).
Please note that I don’t own this exact system, so I can’t verify its actual hardware configuration or performance. I haven’t ever used the supplier SZMZ before either, so I can’t vouch for their delivery times or packing. Another point to note is that although SZMZ has a very impressive 100% feedback rating, it is only based on two orders (at the time of writing). All the same, this looks like a nicely built mini-pc (with more ventilation holes than equivalent models, if nothing else).
‡ — As to the strangely worded phrase in their advert, I’m working on the assumption that what they’re trying to convey is that different builds and versions of this model are available …or maybe the copywriter just took this chance to broadcast their views on men in general.
Here’s another silly one for you. What do you do if the latest release of your OS of choice ships with ZFS, but you don’t have space in your laptop for a second disk? …Answer:- Reach for the velcro.
This Sony Vaio has a Centrino Core-2 p8600 processor, so it’s not going to break any speed records, but it works well enough for day to day use. Courtesy of the Buffalo 500GB SSD taped to the lid, it now sports 1TB of disk space (500GB mirrored), which is probably well in excess of what the designers originally envisaged.
This is one of those little “because I can” projects which I don’t necessarily recommend to anyone else, but at the same time, the lightness of an SSD compared to a normal hard-disk (even a 2.5″ one) means this is now an eminently practical solution if your old laptop happens to be running out of space (I do move the laptop around the house to work in different rooms at different times, but it generally doesn’t travel much further afield than a deck-chair out on the veranda).
So, will it mirror? Heck yes!
Should I mirror?
No, probably not. It’s much more sensible to use a periodic ZFS send/receive job to back up your work to an existing server, that way you don’t need to worry about the extra drain on your battery and you still have your work if your laptop is stolen or knocked off the deck of your yacht, mid-ocean (what, you mean that’s never happened to you?).
One other consideration when thinking about installing Ubuntu on ZFS — currently (as of 21.04) Ubuntu will not allow you to edit the size of the disk partitions; you must accept their optimized defaults. Unfortunately , those defaults include a /boot partition which is much too small (typically 2GB). It will work fine for a couple of months, but with every apt update, the system will automatically add a snapshot of the boot partition. When the upgrade includes a kernel update, this means that tens, or even hundreds of megabytes of storage can be used. Even when you set the system defaults to compress the kernels using “xz”, it doesn’t take too many updates before you start getting “not enough free space” messages from apt and it will refuse to continue with the update. This is not something a novice user can easily recover from (hint: deleting files on a ZFS partition doesn’t always return that free space to the system — it all depends on whether it is still being held by a snapshot).
I’m working on a simple little project (ESP01S-based) right now which needs to be able to sense a warm body nearby, so naturally I turned to my stock of IKEA OLEBY sensor lights (having hacked several in the past and having been impressed with their all round, mmm …cheapness). For such a bargain price, it was almost worth buying them just for the battery holder, but an ancient grey-beard like me really needed a couple for their intended purpose …to light the way to the toilet at 02:00. So I bought a small stock of them (not enough, as it turned out), ripped out all of the white LEDs and replaced them with a single, yellow one and added a CDS sensor on pin 9 of the BSS0001 chip to ensure that they only switch on at night. A couple of them have been sitting (out of kicking range) on the stairs for several years now and are worth their weight (without batteries) in gold.
Anyway, when the need came up for the warm-body-sensor, I immediately thought of the depleted stock of OLEBYs sitting in the drawer, still in their original packaging. As I mentioned above, I wanted the sensor to interface with an ESP01S, so that I could MQTT the heck out of any warm bodies that came into range in the middle of the night (I’m totally screwed if the intruder happens to be a zombie of course). The reason the OLEBY and ESP01S are such a good fit is that the sensor will be working in the middle of a field …and the bodies in question (zombies or not) may not always be human shaped. The field in question is outside of mains-extension-cable range, but is still fairly close to our house; close enough for an ESP to be able to piggy-back off our WiFi network. The idea is that the OLEBY will trigger as usual, but instead of turning on a bunch of LEDs, it’ll turn on the ESP8266 instead. The ESP will boot, latch the power switch on (as the OLEBY will time out if not re-triggered) and then quietly send an alert message to our MQTT server, which we can then act upon depending upon how close to harvest time it is (lights, noises, hand grenades, dynamite or 200W rendition of Slade’s “Merry Christmas” …no, you’re right, that last one is probably banned by the Geneva convention).
So, poking about in the (fairly manky) guts of a dismembered OLEBY (don’t they have any de-fluxing solution in the middle kingdom?) trying to find where the trace from pin-2 went before it hits the LED switching transistor/FET, I discovered something interesting. The brand-new batteries I’d just slotted into the thing measured a pretty reasonable 4.83 volts …but the output from pin-2 measured 5.1v. Eh?!?
In all of the times I’d had the backs off these things, I’d never really looked closely at anything very much beyond the BSS0001 chip or the LEDs, but it seemed like there was something quite interesting going on here. There’s no mention of a charge-pump in the BSS0001 datasheet, so what was happening?
The answer appears to be in that clump of components across at the left-hand side of the board, away from the sensitive BSS0001, where an electrolytic capacitor sits on the reverse (LED) side of the PCB. Something needs a little bit of smoothing (first clue). Now that I get the magnifier out, I can see that a three-pinned device which I’d assumed was a transistor driver for the LEDs is actually labelled as “U1” (second clue). And there, hidden in plain view right next to U1, are a fairly chunky diode and another component labelled as “L1”. Well, who’d have guessed it …the humble (and don’t forget cheap) OLEBY has a fixed-voltage, boost regulator inside it. No wonder the things never seem to lose any sensing range, no matter how dead the batteries get.
U1 is something of an enigma. There are no particularly legible markings (“E502”?) on the chip itself and, until today, I would have been willing to bet that there was no such beast as a three-pin boost regulator chip. To begin with, I was working on the assumption that it was probably a transistor being driven by a clock signal from the BSS0001. However, a Gewgull search first turned up the ON Semi NCP1402, five-pin, micropower regulator, where one pin is marked as “NC” (no connection …hah, maybe the “NCP” part of the NCP1402 stands for Non-Connected-Pins!) and yet another, the chip-enable pin, can be permanently tied to the output pin, so we have at least a theoretical three-pin boost regulator after all. A little more searching through supplier product listings produced a couple of entries for SOT23-3 devices, like the TI TPS613222. So there is such a thing as a three-pin, SMD, boost regulator chip after all. Not only that, but the link to the TI datasheet above will open at an example circuit which seems to be a perfect match for the OLEBY layout (although the actual pin assignments for the TPS613222 don’t match U1).
I’ve just checked the on-line IKEA catalogue for the OLEBY sensor light and, here in Japan anyway, they still have them in stock (although the colours seem to be limited to black, white and red …and the price seems to have gone up, too), but it may still be worthwhile picking up a few the next time you’re in your local store buying some kitchen cabinets, coz’ now you know you’ll be getting a handy-dandy, micropower regulator for your battery-driven projects as part of the deal (oh, and lots of extra flux, too).
If the non-zombie detector ever gets to the decent working prototype stage, I’ll publish another article with the details and link to it from this page (but don’t hold your breath).
While trying to install the DHCP server daemon on FreeBSD 12.1, I got the error:-
Failed to start dhcpd. Could not find dhcp-sync in services file.
This actually means what it says. If you happen to have syncing of DHCP lease information enabled between multiple servers (master and back-ups in the same domain), then you need to add this line to the /etc/services file:-
dhcpd-sync 8067/udp # dhcpd(8) synchronisation
As the dhcpd (server process) runs as user “_dhcp”, you should probably make sure that “_dhcp” has write permission on the /var/db/dhcpd.leases file, too.
Hey WordPress, just a short note here (seeing as it’s next to impossible to write anything any longer) to let you know how much this user -detests- the new editor. Hope you’re not betting the farm on it.
“Xreef” (Renzo Mischianti) has just updated his excellent LoRa E32 Series Library to fix a memory leak issue. All of his examples have also been updated to include the fix, so if you’re thinking of playing with some of the EBYTE manufactured boards and an ESP8266 or ESP32, this is the go-to library (and Renzo has also produced a couple of adapter boards to make it easier to use the E32 boards with your favourite ESP).
NOTE:- This article was originally written mid 2019, but was never posted (it seems that I received a non-maskable interrupt in mid sentence and never got back to it). Prices quoted are probably no longer valid, but I note that the systems themselves are still available from the supplier linked-to below.
As noted a couple of months back in the Odd Bargains post, I’ve been experimenting with some low-cost Celeron-based systems (in addition to the original Z8350, Atom-based unit, which started me along this particular track) as cheap, complete servers for our home network. The main advantages for me are good OS support for most (but definitely not all) peripherals, RTC and battery as standard and they all come complete with a case and power-supply included in the up-front price. They are a lot cheaper to run too, as these low-end processors were originally intended for laptops and tablets rather than full blown PCs. While there’s no denying that the CPU performance is generally nothing to get too excited about, they (the quad-core units, especially) still work remarkably well as 24/7 infrastructure servers for services such as DNS, NTP, DHCP, low volume web servers and reverse proxies. Most ,but not all, come with a GbE port and are quite capable of handling significant amounts of traffic (…watch out for the low-end “ACE PC” branded models though, as they only have a 100Mb port), but all GbE chipsets are not created equal and my tests with a cheap, external USB-3 to GbE dongle (as a super-budget firewall) were a resounding failure (the internal port on the Celeron box could handle the traffic, but the dongle would give up the ghost after 2 or 3 hours).
I found along the way that there are quite a few, virtually identical systems in this price range which have completely different chipsets. Most of the very low cost machines come with Realtek chips, which research on the ‘net shows to be less than ideal for a firewall (the symptoms reported are similar to my own experience with the USB-3 dongle). This isn’t to say that the Realtek chips are to blame (there are lots of other variables in the mix), but it is fairly common to see posts recommending Intel chipsets for long term reliability under heavy load. So, after playing around with a couple of systems that I actually have and taking into account reviews and research, I eventually came down to the choice of a J3160 based system with four, Intel-based GbE ports (the J3160 because it’s a quad-core chip with slightly better performance than the Z8350 and (importantly) with AES-NI hardware cryptography support and four ports because I need to provide for a couple of “guest” networks, firewalled off from the main, home network).
I found a reputable looking supplier on Alibaba who had a lot of good feedback and decent prices (they sell under the names of “Yanling”, “Minisys” and “iWill”). The model I chose was their Nuc-C3L4. In addition to the four (Intel) GbE ports, it also comes with dual-HDMI, 2x USB-3.0 and an RS232 console port. The cost for the bare-bones unit is was $142.60, but that doesn’t include shipping (which was an additional $20 for my location). This vendor does accept PayPal, but only from a limited range of countries (and mine wasn’t one of them). Depending upon where and how you’re shopping, you can probably get 4GB of memory and a 64GB eMMC card for an additional $30, or so. And yes, because I have used this supplier and had a good experience with them and their products, I do recommend them. Communications with them (in English) were easy, fast and friendly. Their shipping was also fast and their packing is excellent (the boxes are sturdy and the units are completely surrounded by a custom, expanded polystyrene foam cushion …which may not be very environmentally friendly, but certainly is effective). The power supply, mains lead and included VESA mounting plate are separated from the system itself by a cardboard divider and all of the individual parts (including the system) are enclosed in their own plastic bags to keep moisture at bay. Once out of the bag, the unit proved to be very black, very shiny and of all metal construction (unlike the Beelink AP35 which I wrote about a couple of weeks back). It looks very nicely made and well put together and it’s obvious that someone put more than a couple of minutes of thought into this very compact design (for instance, the bottom of the unit has ventilation slots and it is secured to the body with four, asymmetrically offset screws, so that it’s actually impossible to attach it in a way which would block those slots).
I ordered memory and an mSATA SSD module from Amazon here in Japan and actually got a pretty good deal. If you do buy one of these units, it’s important that you only use the low-voltage (1.35v) variants of the DDR3 SODIMM, though; this system won’t work with higher voltage rated memory.
Here’s where I hit a very small speed-bump in the road to getting it all working. It turns out that the motherboard slots are not identical. You have a 50/50 chance of getting it right when installing the mSATA …and I got it 100% wrong.
As you can see, the mSATA module needs to be plugged into the right-hand socket to be correctly recognized by the system.
Take another look at that “This way!!” photograph again. The first point of note is the RTC battery (the yellow blob in the bottom, left-hand corner). This system comes with an RTC and battery, which means any Unix-based OS works right out of the box; just tell the OS what timezone you’re in and you’re done. Notice also the row of RJ45 sockets at the L/H side. If you click on the image to get the full-sized version (it will open in a new tab), you can easily read the MAC address assigned to each port. It’s probably worthwhile making a note of those (they’re sequential) while you have the bottom off, to help with identification later.
You can also see there’s a SATA port available on the motherboard, but with this particular model there’s no space available to fit an internal drive.
Here’s a partial dmesg output from the machine once FreeBSD was loaded, showing the CPU features for the J3160:-
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-RELEASE-p4 b0ff15badd(RELENG_2_5) GENERIC amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final) (based on LLVM 6.0.1)
VT(vga): resolution 640×480
CPU: Intel(R) Celeron(R) CPU J3160 @ 1.60GHz (1600.05-MHz K8-class CPU)
Origin=”GenuineIntel” Id=0x406c4 Family=0x6 Model=0x4c Stepping=4
Structured Extended Features=0x2282<TSCADJ,SMEP,ERMS,NFPUSG>
Structured Extended Features3=0xc000000<IBPB,STIBP>
TSC: P-state invariant, performance statistics
real memory = 4294967296 (4096 MB)
avail memory = 4002127872 (3816 MB)
Event timer “LAPIC” quality 600
ACPI APIC Table:
WARNING: L1 data cache covers fewer APIC IDs than a core (0 < 1)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
Close to the end of the “Features2” line, you’ll see “AESNI” included. These are Intel’s “Advanced Encryption Standard – New Instructions” which enable faster, hardware-assisted encryption and decryption. Although this technology is now available on some other processors (including ARM), older Intel processors don’t have it (for instance, the predecessor to this mini-pc system had a Celeron J1900 processor, which doesn’t have AES-NI), so a J3160 is worth the extra few dollars if you’re planning on a VPN server, for instance.
I actually got two of these systems, one for my own use (to replace an ancient firewall box) and one for a remote site. They’ve now been running for almost exactly a year (since I began this article in early August, 2019) and have been totally reliable during that time. I did think that the heat-sink was running a little bit on the hot side when I first installed them, but the “touch test” is deceptive and even during the mid-summer heat, the processors barely register 50°C.
The systems handle the traffic we pull through them without any problem and can handle multiple firewalled VLANs, encrypted VPN traffic and multiple physical networks with ease (as well as handling the normal associated processes — NAT, DHCP, DNS, NTP, etc). I’d like to emphasize what good value these little systems are. Not only is the initial purchase price very low, but the lack of fans and the 6W (avg TDP) processor mean the power requirements (and hence the monthly electricity bill) are low, too. I was also very impressed with the quality of the (all metal) case, the general design and workmanship, as well as the packing and delivery from the vendor. They may not be as cheap as a Raspberry Pi, but the quality of the case, included PSU, cables and accessories, as well as the RTC (and battery) and four GbE ports more than make up for that. You won’t be running a 20TB database with 200 concurrent users on one of these machines, but for moderately light 24/7 operations for a good sized household or small business, I don’t thing you can go far wrong.
Regular readers will probably know by now that I’m enamoured of the tiny, all-in-one, Intel-based systems generally referred to as “Mini-PCs”. They are more expensive than a Raspberry Pi, but they come with a case, a PSU, an on-board RTC, generally a decent amount of memory and sometimes built-in eMMC storage, too. Prices have increased over the past few months (the C-19 effect, again), but the bottom-end models (generally the quad-core Atom Z8350 equipped systems) are still available for around the $100 range (GearBest, FastTech, CDiscount, etc).
I already have a few of these mini systems and one which underwhelmed me on first impressions was the AP35 Beelink J3355-based box, mainly because it was advertised as “fanless”, but does have a CPU blower and because the eMMC just would not work reliably. I gave up on the eMMC and put in a small, internal SSD and since then it has been giving sterling service as a mini NAS (ZFS filesystems with TimeMachine as a backup server for various Macs) as well as running a couple of Bhyve virtual machines (doing very light duty). Once I stopped trying to use the eMMC and put it in the basement “computer room”, my opinion of it increased considerably. It’s a little work horse and, although not a speed monster, performs well enough for my requirements and has been absolutely reliable over the past year (again, since I gave up on the eMMC).
I mention that system specifically simply because I’ve been keeping an eye on prices, with the idea of adding another machine to the collection, if the price is right and the target machine has more than two USB-3 ports. I’ve noticed that there are a few other J3355-based models appearing, with a form-factor pretty much the same as the Z8350 systems and priced in the same general area (ie:- the bottom end of the price range). One thing which I’ve noticed recently though, is that almost all of the advertisments for these systems specify the J3355 as a “quad-core” CPU chip. It isn’t. Here’s an excerpt from the dmesg output of the AP35:-
FreeBSD 12.1-RELEASE-p6 GENERIC amd64
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1)
VT(efifb): resolution 800×600
Skipping TSC calibration since no legacy devices reported by FADT and CPUID works
CPU: Intel(R) Celeron(R) CPU J3355 @ 2.00GHz (1996.80-MHz K8-class CPU)
Origin=”GenuineIntel” Id=0x506c9 Family=0x6 Model=0x5c Stepping=9
Structured Extended Features=0x2294e283
Structured Extended Features3=0x2c000000
TSC: P-state invariant, performance statistics
real memory = 4294967296 (4096 MB)
avail memory = 3894444032 (3714 MB)
Event timer “LAPIC” quality 600
ACPI APIC Table:
WARNING: L1 data cache covers fewer APIC IDs than a core (0 < 1)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
Having said all of that, here’s a link to a system on FastTech’s site to an MII-V with 4GB/64GB, GbE and four USB-3 ports which, at $112.45 (with free shipping), seems to be the best, generally available deal on this class of machine at the moment …just remember, it is DUAL-core (no matter what they say).