Thoughts on RAM

These are just thoughts – hopefully someone is going to write in and tell me I have it all wrong.

As regular readers will know I have reviewed (and messed with) MANY small Pi-type boards including the Raspberry Pi, Banana Pi, NanoPi etc etc.  I’ve also had a go with some power supplies and even made up my own solutions at board level. We’ve had discussions about the issues with FLASH and minimising writes and so mentally it all seems to be coming together. What is needed for our home control central control projects is:

A cheap SBC with enough RAM to be able to lose some for LOG2RAM and buffering for datbases etc to utterly minimise writes to FLASH – so ideally maybe once per day, stuff in RAM would be written to FLASH.

To go with the above then – clearly a power supply is needed that will not fail – i.e. with battery backup.

Sure, if you through enough money at this – there are solutions for everything but at a budget?

Firstly, RAM – just not enough – some of these boards have 256Meg and 512 Meg  – enough for normal use but if you start stealing some of it to run Log2RAM and RAM-buffering databases (RAMDISK) then you start to run out – it seems to be that 2GB of RAM would be a nice figure yet I’m only aware of a small number of these boards that have this much – if memory serves me well, the Odroid C2 – and a board I’ve only just recently heard of – the FriendlyArm NanoPi K2. There will be one or two others I’ve long since forgotten.  The Raspberry Pi people for example apparently have no intention of moving to 2GB in the near future. We see people using these boards for media management yet if you look at the notes from the designers of such software they usually suggest 2GB minimum RAM!  I don’t do media management but our chats about FLASH have me using Log2RAM and RAMDISK and depending on your needs you could be looking at losing 512Meg or your precious RAM.

Power supplies – especially important given the above – recent testing has shown that we don’t seem to have a single low cost unit available that can handle the battery going down to zero – and recovering gracefully while the the load is connected or having to press a button or some impractical manual interjection – and bearing in mind that several of the better boards need  2amps+.   Looking back through the blog there is not one – there’s one on Kickstarter but that is now way, way late in appearing and for all we know THAT might not do the job.

What are people’s thoughts – am I talking nonsense? Am I missing some products? What do you think? Do people have low-cost solutions I’m not aware of?


36 thoughts on “Thoughts on RAM

  1. Despite the lack of RAM, my vote goes to the Raspberry Pi simply for support, longevity and the sheer size of the user base. None of mine run the GUI, and I haven’t run out of RAM (yet).

    Here in Crete (after migrating like the Scargills) I’ve just retired a 2012 Pi1 and replaced it with a Pi3, needing only a tiny change to the software. I’m fairly confident that when the Pi3 needs replacing, a Pi(x) will do the same. How many of today’s chinese xyzPi boards will be around or supported in a couple of years? (months even?)

    I must admit I’ve been upgrading PSUs following tkaisers comments a few blog posts ago.

    Finally, I’ve attached a photo of a Pi I saw controlling the departures board in a hot, dusty open-to-the elements bus stop here. I can’t imagine leaving a Pi, router, 21″ display etc in a bus stop in the UK somehow…..

  2. My Scandisk Ultra SD card won’t boot now so I ordered a Smasung EVO+. The Current EVO I have is working well. USB sticks are not made to be abused by a DB and cheap ones will fail quickly.

    As for RAM Ebay has plenty 64GB SSD for very cheap ~$25 or less.
    I live in South Florida so brownouts happen once in a while so my Pi3 and NAS are under a UPS. If I move this rout I will have to change power supply, I also peppered the house with plenty MOVs.
    Pete – As per your Spain problem a friend in rural Italy has the same problem. We had a few industrial MOVs installed in their Bed and Breakfast.

  3. What about using a USB stick for the databases and logs instead of RAM?
    Lets say that databases and logs are backed up to the cloud on a regular basis, say once a day… in that case it wouldn’t be too bad if the usb stick failed, and they are cheap and replacable? While the main system on the SD card would keep operating.

    What do you guys think?

    1. I tried that out (using an USB thumb drive for a workload requiring high random IO performance) and it failed horribly:

      Using real SSDs behind an USB-to-SATA bridge is both somewhat weird (since performance will be limited) and expensive but on the bright side all those better SSDs (speaking of Samsung, Crucial and Intel here — never used other vendors) expose internal parameters via SMART, especially a ‘wear out indicator’ that works like a counter you can react on if you fear flash media wearing out too fast.

        1. The USB thumb drive hosted a whole virtualized Linux active as Armbian build host (all those new OMV images for ODROIDs and other ARM platforms over there were created that way on my MacBook). The IO pattern might be comparable to a database though (mostly random IO).

          I tend to agree with @’Scott Macias’ that USB thumb drives mostly are not up for the job (random IO workloads).

          But back on topic: the ‘need more memory’ problem can be solved both by throwing hardware at it (larger DRAM) or software (more efficient use of available memory — speaking of concepts like zram here, we’re currently starting to explore this in Armbian since more and more boards are supported by recent kernel versions 🙂 )

  4. I use a Cubietruck, which is a Cubieboard3, with all the bells and whistles. It has 2Gb RAM, built in WiFi, Bluetooth, there is a 125GB ssd and battery backup. I paid $125 CDN, which I found quite reasonable. It has been running for 2 years with ArmBian without a glitch.

    1. Thanks – and yes, of course you can put an SSD or hard disk onto the Pi – kind of increases the cost though unless you got them for nothing. And for the benefit of readers who followed the blog entry about SD – I’m pretty convinced now that the major issue with SD reliability is actually the power supply. However, we do know that the SD cards do have a limited life and if doing database bases, potentially very limited life – so it is still worth progressing this conversation.

    1. Would be good but for the price! One could buy, erm, a lot of Orange PIs with that. Still. Also I think it is from the USA and we know how customs in the UK and Spain (and probably others) like to go with a vengeance at anything from the USA. nice to know it is there. Powerful no doubt. I didn’t see anything about battery handling though.

  5. To solve the problem with single or multiple points of failure install mirrors:
    – install mosquitto on 2 OPI and mirror servers
    – install mysql on 2 OPI and mirror
    – to mirror node red just use rsync

    O course is not easy to configure, but in this way you will have a good Wifi coverage for your sonoffs which is very important, the system price is still low and the mirror solve the single point of failure problem.

    I am using armbian which is a great OS for OPI.

  6. Instead of install all the software on one SBC and run out of RAM, try to use more OPI zero. For example:
    – put 4 OPI zero in all 4 corners of your house
    – configure all of them as AP and router with the same SSID and password, but different channels
    – install mosquitto on the first one, mysql on the second, node red on the third …..

    In this way your system will have 2Gb RAM and a complete WiFi coverage of your entire house

  7. I uses memory stick as RAID-5 and only /boot left on SD card.
    And how much memory is needed Depends on what you run. I run virtual systems with 128 MB RAM that doesn’t Swap.
    You should test, as the use might surprise you.
    Swap are not usually a problem, it doesn’t use it as much as one might guess.
    And if you don’t run a graphical environment, I would be surprised if you need more than 512 MB RAM. Even with a database running.

  8. I use the LiFePO4wered/Pi3 and while not exactly low cost ($42) it is a reasonable price in my mind to save me the hassle of having to repair sd cards.
    It is also configurable with how it shuts down and restarts the Pi. The command line tool also means it can log to and be configured via node red for remote management and monitoring.
    From its manual:
    1 byte, register address 0x18, read/write, saved to flash
    Default value: 0x00
    When this register is 0 (AUTO_BOOT_OFF), the LiFePO4wered/Pi3™ will stay off until the user touches the on/off touch pad to turn the Raspberry Pi on.
    Setting this register to 1 (AUTO_BOOT_VBAT) will make the Raspberry Pi boot immediately when sufficient battery voltage is available (VBAT greater/= VBAT_BOOT threshold). This is useful when using the LiFePO4wered/Pi3™ as a UPS to maximize uptime.
    Setting this register to 2 (AUTO_BOOT_VBAT_SMART) will make the Raspberry Pi boot
    immediately when sufficient battery voltage is available, but only if the unit was previously shut down due to a low voltage condition. This makes it so the user can still choose to turn the Raspberry Pi off with the touch button or from a user program.
    Setting this register to 3 (AUTO_BOOT_VIN) will make the Raspberry Pi boot if sufficient battery voltage is available (VBAT greater/= VBAT_BOOT threshold) and the USB voltage is also present (VIN greater/= VIN_THRESHOLD). Setting the register to 4 (AUTO_BOOT_VIN_SMART) enables the smart version of this setting, which allows the user to shut down the unit manually as described above.

    2 bytes little endian, register address 0x1A, read/write, not saved to flash
    Default value: 0
    This register allows the user to set a time in minutes that determines how long the Raspberry Pi will stay off before the LiFePO4wered/Pi3™ will automatically boot it again.

    2 bytes little endian, register address 0x16, read/write, saved to flash
    Default value: 0xFFFF
    Auto shutdown is a feature that will shut down the Raspberry Pi if the input (USB) voltage falls below the VIN_THRESHOLD level. The shutdown will happen after a delay in minutes specified in this register.

    1. Looking through those solutions – sadly most are far from inexpensive – I quite like the look of the Banana Pi BPI-M2 Ultra myself. As for the Pine-64 – well as you know that didn’t work out too well otherwise! I use mine as a doorstop 🙂 Orange Pi – we know has zero support outside of the Armbian guys…. yes, the ~Banana Pi……. maybe worth a look….

            1. While I agree with Pete that OrangePI SBCs are severely lacking in the support department (would it kill them to not push our two each week and maybe support the one’s they have put on the market?), the one thing I really like on my Orange PI PC is the power barrel connector. That thing NEVER falls out on its own or by accident, I bet I could swing it in a circle over my head on the power cable (new sport?) and it would just carry on working.

              All the other “Pi’s”, NanoPi2 Fire and all Raspberries 2/3/ZeroW I use, I really have to handle those with the utmost care, as the MicroUSB connection is rather flimsy, and I am already using the tightest Micro USB cables I could find which do not cost a fortune.

              1. only drawback is that’s a non standard barrel connector, not the usual 5.5×2.1mm, but i think is something wanted to prevent inserting 12V as most of the 5.5×2.1mm barrels are 12v… yes, there are 5v too, i have many, but maybe safety first… sure you can always use an adaptor and put in 12v anyway 😀

            2. Forget about the Plus 2 (way too expensive and using the crappy/broken GL830 USB-to-SATA-bridge). The Plus 2E is something different and my personal recommendation if you need 2GB DRAM since it also has *really fast* 16 GB eMMC on board.

              Software support is great too (thanks to linux-sunxi community).

              And while I personally don’t like Allwinner’s A64 that much the new OPi Win Plus $whatever (A64, 2 GB DRAM) seems like a good choice if you need battery too. A64 software support by vendor is horrible (as with almost every other Allwinner design) but community does a great job.

        1. Banana folks have now or soon 8 boards with 2 GB DRAM but I can’t recommend any of them since they even fail to provide correct schematics. The eMMC on all their boards released after BPi M3 is also very slow and the same applies to the SATA port here too. Details available in Armbian forum. And before you buy Banana products please check out their forum regarding ‘support’:

          On the bright side: some brave linux-sunxi souls are still working on M2 Ultra so later this year or next year we might be able to run sane/clean kernel/distros on the M2U too.

  9. i for myself settled for the raspberry pi on the solution to simply attach a ssd-drive via an usb-sata adapter, this ssd does not have a problem with many writes an it is cheaper and simplier than tinkering with UPS and read only filesystems or redircting to ramdrive…

      1. the shared bus between usb+eth on the raspys is the bottleneck… yes, an ssd is better than a mechanical drive, otherwise just go for the official pidrive+berryboot

        i think with the mod i did a while ago to enable the experimental usb boot i can now boot from hd, too… for now, i’m using a fast usb3 dongle, which WAS fast before attaching it to the rpi3, now i can’t see different performances towards the earlier microsd…

    1. Of course – the power supply solution need not BE expensive – just needs something to think when they are designing – so many cheap solutions are ALMOST there. I have a board at £3 from China – you wire a Lithium battery to it and you are all set to go – I’ve blogged about it – almost perfect – but I only recently discovered that if the battery goes completely flat (a good example. the power went out here due to earth leakage – could not get someone to flip the fuse for a day) and when it came back up – nothing from the supply… disconnect the load just for an instant and reconnect – and all is well – just a LITTLE more thought into the design….

        1. You have me thinking now…. an ESP8266 complete with relay…. has an analog input! Read the battery state – warn the Pi to shut down…. then run on the battery itself – not it’s power unit….

          Turn off the Pi. Watch for battery improvement – if improves, turn load back on..

          From power up (assuming it all went badly and battery went totally flat – go back to watching for improvement and turn back on after a while..

          Meanwhile can ALSO act as a watchdog – if no comms from Pi for more than a certain amount of time when supposedly on – reboot by cycling power…

          Would need it’s own supply to make best use of varying battery voltage —- hmm, worthy of more thought there.

Comments are closed.