Paintchips Random Projects and Tech Blog

Squeezing Performance Out Of a Raspberry Pi
I’ve seen a bunch of cringe inducing posts on the official forums of the Raspberry Pi Foundation, ever since USB boot was added the common suggestion “use a USB flash drive” instead of a SD card and the end result is users crying about write speeds being worse than a SD card. There is a right way to squeeze I/O performance from a Raspberry Pi, if you go the USB flash drive route it’ll cost almost as much as a good MicroSD card for at least a 50 MB/s write speed. In my opinion on the low cost side a 128GB Samsung Evo Select MicroSD will provide a 90+ MB/s read and 58 MB/s write for under $18 on sale–since Amazon is doing pre-Prime Day deals its currently priced at $16.49.

SSD prices have dropped in price over the last several years, instead of buying an expensive $29-35 flash drive there are some budget SSDs you can throw into a USB enclosure for 400+ MB/s read & 350+ MB/s write speeds with a much longer MTBF. Even the cheapest 120-128GB SSD with a 400 MB/s read and 350 MB/s write can be found for $12-16 USD, pair it with a $8.99-9.99 enclosure and your Raspberry Pi will be extremely fast. (I’m planning to benchmark more SSDs)
SSDs Worth Recommending:
Fanxiang S101: The 128GB & 256GB versions sell for $15.99 and $21.99, this brand came to mind as the performance is on par with PNY CS900 series SSD at a much lower price point.
Inland Professional: 120GB model goes for $18.99, while I wasn’t impressed by the read speeds of the 240GB model the write speeds did have peaks at 425-ish MB/s but averaged at 385-390 MB/s.
PNY CS900 120GB: At $21.99 its still pricey, however I’ve used one for heavy I/O usage since 2019 and the speeds haven’t dropped off.

I had a class 10 brand new Samsung Evo 64GB SD Card and the performance was absolutely horrendous, at least on how it felt in day to day tasks. I already had a m.2 Adata XPG SX8200 and it was lacking a home, so I bought an external USB enclosure with NVME support and the difference is night and day in terms on how responsive the desktop feels. Unfortunately the enclosure doesn’t have either TRIM nor SMART support, which sucks for the life of the SSD, but I’m not exactly writing it 3 times a day its full capacity. Besides, I use a NAS with a spinning rust where I download the content to watch, then delete them, the HDD is disposable basically.

Main PC = RPi 4 8GB.

If you dig into reviews Samsung lowered their Evo 64GB from U3 to U1 so it only reads 60-70 MB/s with slow write of 20-30 MB/s, I made that mistake awhile back when I sourced a card for a Rock64 board. With a fast U3 card performance is good enough for most, SSD is more ideal if using a Raspberry Pi as a desktop.
The risky part of NVME enclosures is not all of them are equal, UGreen makes one with TRIM & SMART but the price is higher than other enclosures. I only used SATA SSDs on my list as most low cost enclosures support TRIM & SMART.

Mine is an older Evo 64GB U3, at least if we are to trust the label on it. Had it for a few years and it barely saw any usage. It is a decent little card, but it seriously doesn’t compare with SSDs.

I have assumed the risk when I continued running the SSD in this enclosure. Not sure about the remaining lifespan of the SSD, but I am planning on moving from the Pi 4 to another SBC, with the best contender being the Khadas VIM4 if I can get my hands on one and an m.2 holder for it, as it has a port, but no support.

Storage Benchmarks
Lexar E Series MicroSDXC 128GB:
Average Read Speed: 98.5 MB/s
Average Write Speed: 42 MB/s
Peak Read Speed: 110 MB/s
Peak Write Speed: 50.2 MB/s
Notes: For most this will be plenty fast enough for most light weight OSes may it be a Raspberry Pi or Pine Rock64, this card is above average since its priced very close to SanDisk Ultra 128GB which typically has write speeds in the 45-55 MB/s range. As with SDXC cards in general you’re at the mercy of the silicon lottery, some cards will have a faster write speed and others will perform close to V30 speeds. I’d also have to note Lexar quality hasn’t changed since Micron sold the brand, you still have a competitive level of flash memory storage price points.

Somnambulist SATA SSD 120GB:
Average Read Speed: 446.5 MB/s
Average Write Speed: 344.8 MB/s
Peak Read Speed: 518.4 MB/s
Peak Write Speed: 400.3 MB/s
Notes: The best value SATA SSD for $13.99 if you were to put this into a USB enclosure and use it with a Raspberry Pi 4.

Eldingu SATA SSD 128GB:
Average Read Speed: 457.5 MB/s
Average Write Speed: 343.8 MB/s
Peak Read Speed: 510 MB/s
Peak Write Speed: 440.5 MB/s

1 Like

I’m more curious about the latency / response times between SD cards and SSDs in USB enclosures. Still, the Lexar SD looks pretty good, but that’s quite the capacity there.

Lexar MicroSDXC has an access time of 0.43 msec
Access time on those SSDs were 0.30-0.35 msec

1 Like

StarFive VisionFive V1
Originally I was going to write about the reasoning of why I was holding off for other RISC-V boards, the StarFive Vision Five V1 is a great starting point of being between a Raspberry Pi 4 & Jetson NX yet the way it allocates memory hurts the actual usage point it was developed for(AI/ML).
The StarFive VisionFive V1 dual-core RISC-V SoC has Vision DSP Tensilica-VP6 for computing vision at 600MHz (VPU), an NVIDIA Deep Learning Accelerator, and a neural network engine. On paper this board is on par with a Jetson Xavier NX, however when you dig into exact specs of how it accesses memory “LPDDR4 memory is divided into 2x 4GB clocked at 2800MHz, which restricts performance, unlike the totally integrated 8GB SDRAM”, this more or less cripples performance down into Jetson Nano territory.

This blog post sums it up best “Even though the hardware supports H264 and H265 video decoder, for live video streaming, the hardware requires more memory to process. SDRAM is split into 2 4x RAM, which limits performance and might not sustain processing for high video graphics.”

CPU-GPU Neutral Workflow
While I haven’t posted any updates on this, I did learn Intel released updated Linux development tools not only for their compute stick but they also expanded support of OpenCL compute on their IGPs. Performance wise compute on their IGP isn’t going to be close to CUDA, however on the lower power side of embedded Intel CPUs such as Celeron J4105 series they may barely be better than a Raspberry Pi 4 on CPU tasks but using OpenCL & QuickSync the IGP makes up for it.

Medical/Biosensor Analytics Project
Had started this project based on how to cross reference training data with a Garmin smartwatch, the goal was more to see how small changes impact workouts/post-workout data.
On a Garmin watch you have the following data collection:
Heart-rate & resting heart rate
Body battery
Pulse Oxygen level

Now you’re wondering how are you going to set a base line. The original experiment was comparing what if you went from a Gatorade to a Monster drink, trade electrolytes for a dose of vitamins with a punch of caffeine. The trade-off was a much higher heart rate, however there was a slight improvement to the pulse ox levels so not everything was completely bad. In the name of science for a 3rd experiment was what if you used Gatorade with 400mg of caffeine, from a performance angle it got very close to a Monster drink. I did experiment with sugar free/natural electrolyte drink mixes, interesting part is some of them actually provided a similar boost of a Monster drink without caffeine.

Post Workout “Stress” Recovery
Since I played lots of sports, I’ve used a bunch of products over the years and a rule of thumb is stick with a recovery formula that helps reduce injury. There are many BCAA products out there, some of them are pure quackery, some use a higher boost of one or two ingredients, there are some which don’t disclose any ingredient list(high risk in my opinion) and there are others which are more of a balanced blend. I’m not going onto a soapbox on what to use/don’t use, just use caution or common sense if a product makes drastic claims. With a “balanced” BCAA product you’ll see a reasonable stress reduction and a small improvement on the body battery status.

Researching laptop battery management
Been researching the batteries and battery management on a few laptops for the possible fuel cell conversion project–I’ll also note the company who took over my fuel cell battery project is likely going to use the laptop fuel cell conversion project data. One interesting thing I observed with HP specifically is the charge/discharge state of the battery is linked to how the power adapter is detected as “Official HP”(similar to Dell too), if you try to charge an HP with a Dell power adapter it’ll still charge but won’t go above 40W.

I’ll note HP “smart charge” typically will rapid charge to 50% so if you had a laptop that was a 45-65W power adapter it rarely goes into full watt mode unless you’re using the laptop like a desktop replacement & even then it’ll draw power from the battery.

Originally I had considered modifying a Thinkpad T470/480 but Lenovo changed the power management. On current Lenovo USB-C models the charge state won’t go above 20W if you use a non-Lenovo approved charger, its still something I’m trying to figure out a way to safely bypass using a circuit breaker protection.

1 Like

Alt Fuel Experiments Lawnmower & Go Cart Edition The 90s Were A Fun Time
When I was younger I had some interesting friends who’d attempt engineering things, lets just say there were lots of questionable judgement leading up to the Go Cart.

Alt fuel for a lawnmower was something a friends’ dad actually greenlit, it was an old lawnmower and it was picky about the grade of gas it used–use budget gas and it would stall due to water content. The goal was to create a biofuel that “worked” and ran clean. Since it was too hard at the time to buy soybeans, the next best option was fermenting rice and it took awhile to get a usable fuel ratio to run in the lawnmower. It took trial & error to get a mixture which was on-par with mid-tier gas/petrol. Interesting part of using fermented rice as a fuel was not only it required less maintenance of the old lawnmower, using it with a modern 90s lawnmower there far less buildup of residue in the engine.

Go Cart Experiment
Everybody knows Go Carts use a similar engine as a rideable lawnmower, the big challenge at the time point was making a reliable rice fuel that remained gas tank stable so if there were any moisture from humidity it wouldn’t be too big of an issue. A friends’ dad came up with an idea, just bump up the fuel quality and do a few experiments of seeing how much moisture build up from humidity would change the stability of the fuel. End result of this experiment was trying to get the perfect stable fuel is stupidly time consuming and at the time period the cost per gallon came out to be closer to $3.50 so at late 90s prices it was 2.2x the average mid-tier gas. I wouldn’t be shocked if using soybeans for fuel might be equally expensive. If I recall when my friends’ dad took apart the engine it was extremely clean almost as if it wasn’t used.

1 Like

Raspberry Pi 4 vs Celeron N4020 vs Celeron J4105
Originally this was going to be Raspberry Pi 4 vs Celeron J4105, however the “Walmart Special” was an unexpected find. From a thermal performance the N4020 has a surprisingly good passive heatsink, while its not that thick, the surface area displaces the heat quite well.

Depending upon how your Raspberry Pi 4 is setup if you’ve given it an active cooling fan or a case which acts as a big aluminum heatsink your performance is going to be on par with a Celeron J4105.
A Raspberry Pi 4 with just a tiny heatsink set is going to end up thermal throttling heavily and drop into a fanless Dual-Core Celeron N4020 level of performance.

Experimental Testing
The testing procedure was more about pulling medical sensor data, originally I was going to use the Raspberry Pi 4 as a fall back hardware option if the wearable PC based on the Quartz64 fell apart and the possibility of using Intel/AMD low-power CPUs were another option on the table(several AMD & Intel boards can run off USB-C at 10-20W).

Raspberry Pi 4 (fan): Real-time medical sensor data processing 99% then dropped 1% more or less was due to the power saving nature of Broadcom Bluetooth… didn’t matter using 32-bit or 64-bit OS, it just burped up. Ubuntu 64-bit the Bluetooth performance was worse. Didn’t bother using a USB Bluetooth adapter as USB 3.0 gave off RF interference since it was booted off a SSD.

Celeron J4105: Real-time data processing worked without any data loss, however having 8GB of memory gave extra headroom. Was running a tweaked Debian which trimmed back unnecessary applications/dependencies.

Celeron N4020: Real-time data processing again worked without any data loss, I used the same tweaked Debian as the J4105 as I trimmed down certain things and the N4020 has 4GB of memory.

Experimental Input
Again this is a work in progress for the Wearable PC project. The goal is have a gesture based input may it be a muscle sensor or a touchpad interface. For this test it was using a touchpad interface to simulate a keyboard input.

Raspberry Pi 4: Multi-word processing bogged down, can’t really say I’m surprised as the touchpad interface keyboard input emulation was originally developed on CUDA and getting my hands on a Tensorflow Lite accelerator is still near impossible to buy.

Celeron J4105: Multi-word processing bogs down or starts to have input lag, not as bad as the Raspberry Pi 4 but semi-usable… it does make me wonder how it would perform on a Ryzen Embedded platform using OpenCL.

Celeron N4020: Multi-word processing was similar to the J4105, however input lag creeped up… for the most part I was expecting thermal throttling but the thermals never played a role in input lag.

1 Like

Slow Process Of Replacing Raspberry Pi 3
While there are upsides in consolidating hardware to a single vendor, there are risks of supply chain hell that we’ve seen with the Pi 4 and it makes more sense to look at options.
With the Pi 4 still being a mess, it makes more sense to look at the best Pi-style I/O with the most out of the box compatibility with most hats.

-NanoPi M4V2: Not really my first pick since it costs $80 USD, however it uses the Rockchip 3399 which is a dual-core A72 at 2Ghz with a Quad Core Cortex-A53 at 1.5Ghz and for the most part is the closest you’ll get to a Pi 4 level of performance with a mixed core solution in a credit card sized board. Only reason I put it at the top of the list is the number of Linux distros supported.

-Banana Pi BPI-M5: Amlogic S905X3 quad-core Cortex-A55, having four USB 3.0 ports like the NanoPi M4V2 makes this the ideal choice. Prices vary between $85-99 so the NanoPi M4V2 sits at the top of the list as the better value.

-StarFive VisionFive 2: A quad-core RISC-V at 1.5Ghz looks good which is an improvement from the original dual-core, price points are decent since there is a 2GB, 4GB & 8GB model options… the only headache is Ubuntu seems to be the only supported OS for a mainstream support OS, while it does list Fedora & Debian were added recently I’m not expecting much on the Fedora side. Since some projects of mine that run on a Pi 3B aren’t that CPU demanding, RISC-V wouldn’t have the scale of risk with trying to run something that expects a Pi 4 A72 level of performance.

Wearable Computer 3.0, High Performance Mobility
With all the effort put into a Pi-style I/O breakout for x86/x64 using a laptop’s built-in smartcard reader slot connector, it opened the door towards “High Performance Mobility” than continuing the “Spudnik Wearable Computer 2.0”. While the Rock64 wasn’t bad, having to use a Bluetooth module for medical/biosensor duty pushed the power usage limits and using multiple input interfaces kept going into low power errors. A work-around on Rock64 was use the 2nd battery pack power port to power a USB hub which required extra cable management–Rock64 isn’t alone in the USB port power issue, USB-C powered Celeron J4125 Mini PCs hit this wall frequently.

Input devices lead to interesting discoveries of what works or doesn’t work. Muscle sensor experiment worked better to accessing OS/UI menus with gestures… experimented with “force levels”(slow vs fast movement) and it made the virtual mouse pointer fly around the screen or scroll too slow/fast in menus. Re-purpose a phone touchscreen as an input device had its own issues, text input lag varied due to trying to tune the digitizer for a PalmOS style Graffiti. If anyone has used laptops long enough you may have used many trackpad makers, for laughs got an Alps trackpad to work via USB and figured out you can do “alt-modes” to simulate a keyboard input via PalmOS style Graffiti. The only downside when it came to language support the more characters/complex input, performance of the CPU starts to make a difference… note to self “don’t go into IKEA level of combining a bunch of words together to get a funny or unique German word/term”.

Keeping the UI clean and only displaying important info makes it look clean, the concept is have a sidebar that displays health/biosensor data at all times similar to KDE/Windows 7 style widgets. On a bare minimal it would perform very good with a 720p based display glasses.

As far as hardware testing considering the Celeron N4020 only weakness was input lag creeping up, I’m sure a mobile Pentium Silver/Gold would strike the balance of multi-core performance to watt ratio.

Are those board even compatible with the Pi hats? I assume you know better than me what you are doing, I’m a total noob when it comes to accessories, but just putting it out there. There are board that have a similar 40 pin GPIO layout, but some may not be pin-by-pin compatible with the RPi, requiring either adapter boards, or ugly F to M wires and manually fitting those together, with maybe excluding some pins from connectivity.

Then, depending on the hat, they may use features only available on the Broadcom SoC, there’s currently no other board offering full compatibility with the RPi hats.

NanoPi & Banana Pi work with most hats with the exception of hifi & PoE, you tend to need to do similar Pi GPIO config tweaking like the Rock64 from what I’ve read. Work wise the Raspberry Pi 3B replacement project doesn’t rely upon hats, Pine64’s Rock64 fills that gap quite well… Quartz64 is still an unknown, need to put one through a bunch of tests. I’ve avoided hats that are Broadcom SoC specific.
StarFive’s VisionFive 2 GPIO is the unknown but I think RISC-V is a tempting platform for a few features it offers.

1 Like

Quartz64 Model B
Normally I would of done testing on both Manjaro and Armbian but the latter would suffer some kind of weird USB port failure between reboots. Keep in mind the weird USB port glitch existed with the Rock64 on the Ubuntu version of Armbian. When it comes to out of the box OS support, Pine64 hardware does a better job with Manjaro and there are many upsides in terms of being a rolling release so fixes/improvements happen quickly.

Stress testing the CPU, when it comes to performance it feels 1.5x responsive compared to the Rock64 under load so even though it would be considered a tiny improvement on “paper” the RK3566 is a huge improvement in a few areas. The biggest improvement is the RK3566 doesn’t really need a cooling fan, in a few extended tests the CPU didn’t thermal throttle and using a simple heatsink did the job. If you do plan on running the CPU at 80-90% load for sustained amount of time, a cooling fan might still be a good idea as I/O performance can still be skewed by system temps.

I/O performance when it came to the USB 3.0 port has been faster compared to the Rock64, for some odd reason the read/write speeds on the Quartz64 beat a Raspberry Pi 4 by a few seconds. Didn’t test the M.2 slot as you’d need an adapter to properly secure a SSD.

Even though the Quartz64 is still listed as “in development” on the Wiki support page, your mileage is still going to vary depending upon use case. OS wise even though support is “developer” level, I haven’t encountered anything that broke functionality yet… GPU hardware acceleration is still the only work in progress.