×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Zippity.

  • Posts: 33
  • Thank you received: 15

Zippity. was created by Brian Davis

READ: None of the below is supported by Stellarmate. <em> Proceed at your own risk</em>

There are those among us always looking to pimp our Pi. I run Stellarmate on my rigs, and have really enjoyed all the convenience it brings, and appreciate the hard work involved in producing it. But speed thrills baby, So I suppose, it was inevitable, that I started tinkering. Having scoured the many (usually confusing) reports and articles about this, I discovered, that it got a hell of a lot easier on June 15, 2020, and not that many folks noticed.
The below are steps generally needed to 1. Overclock your Pi 4b (and probably 3's as well, but untested), and to run and boot your Pi Stellarmate installation from a USB3 SSD drive. No SD card needed. When complete, it's a good bit quicker. A GOOD bit :)

So far, this is running flawlessly on my rig. I live in Texas, and it's been in the hundreds here for about 3-ish weeks. Fully overclocked with the settings below, imaging all night with max nighttime temp starting at 107, and low temp about 83, the Pi never missed a beat, and stayed reasonably cool (65C).

I use a 60W USB3 hub from Plugable, and I never plug anything but the hub into the Pi4b. However, I've included a tweak that helps a bit with the wambly USB power issues caused by plugging devices into the USB bus on the Pi (forums full of problems on that). The SSD drive (a half terrabyte Sandisk that costs $69 on Amazon) plugs into the Hub, and boots the Pi from there.

I also installed the Pi in a new case, with heatsinks and a cooling fan. The better the cooler, the faster you can clock it. Doubtful you'll get far overclocking without new cooling. The SSD doesn't need it at all, FYI.

You need to start from a running Pi, with whatever Linux dist running on it.

From the terminal prompt, do the following:
#Lets get the new bootfromusb bootloader, and install it.
1. sudo nano -w /etc/default/rpi-eeprom-update
2. change the FIRMWARE_RELEASE_STATUS value from "critical" to "stable"
3. ctrl-x and answer yes to save
# This installs the boot-from-USB Bootloader
5. sudo rpi-eeprom-update -d -a
6. sync;sync;sync;reboot
# Check to make sure it succeeded
7. vcgencmd bootloader_version
8. Verify date of bootloader is newer or equal to June 15, 2020
9. // Didn't work? Likely usb issue. go fix. Remember what I said about unsupported? If you don't posses the skill and determination (it takes more of the latter) to track down the issue and fix it yourself, you probably shouldn't be tinkering with this crap. Shoot images instead.
10. sync (force of habit)
11. Powerdown and unplug power supply

Ok, now we have the bootloader in place, so lets install Stellarmate on the SSD

Option 1 - Migrate existing install

1. Power on, then log back in
2. OPen the "SD Card Copier" app found in Accessories menu in Stellarmate desktop.
3. Select SD card as source, and SSD drive as destination. The SSD will be wiped completely out, and reset during the copy operation.
4. Start the copy, and go eat lunch.
5. Once copy complete, remove the SD-card and keep it as a fallback, in case you run into problems.
6. Power off then on. Presto! (we hope. if it blows up, just put the SD card back in, and reboot, and figure out problem, and fix, but worked no issues for me.)

Option 2 - Fresh install

1. Use BalenaEtcher to burn the distribution StellarmateOS image to the SSD. Do it exactly the same way you would with an SD card, except select SSD drive as destination.
2. Once copy complete, reboot RPi and presto!

Tough hack eh? Boot from USB is now native to RPi4 !

<strong>Overclock the Pi</strong>

1. From the terminal in Stellarmate, do the following:

stellarmate@stellarmate:~ $ sudo nano -w /boot/config.txt

<em>Add the following lines at the end of the file:</em>

over_voltage=6
arm_freq=1750
max_usb_current=1

Editors NOTE 9/7/2020: Now strongly suggest not overclocking the GPU. This settings has some unexpected effects on various system clocks, and can result in problems occaisionally. Given that keeping accurate time on a running Stellarmate box is pretty important, I suggest not modifying the GPU settings.
#gpu_mem=256
#gpu_freq=600



hit ctrl-x and Y to save the file.

Over_Voltage gives the chipset a little more juice. Max_usb_current bumps up the power supplied to the USB ports. The Pi4b defaults to 600mA (total) on all USB ports. This command bumps that to 1200mA. That's probably still not going to be enough to run a bunch of power hungry gear, so better keep using the powered hub).

These are conservative freq numbers, because again - Texas heat, but many people have reported stable boards with arm_freq as high as 2147, Feel free to experiment with higher settings. The GPU boost actually helps more than the arm boost. The SSD really makes it run noticeably faster in so many places though. So for improved performance, start with the SSD drive. The RPi runs hot though, so I wouldn't do much overclocking without adding heat sinks, etc.

I tried this again this morning, with a fresh install of 1.5.4, No issues noticed at all. Its rocking right along!

HOWEVER.

My Dad used to tell me: "Son, trust everyone the same way you want to be trusted. <em>But brand your calves boy</em>." So I backup my Ekos configs and keep an working SD card with me, just in case.
The following user(s) said Thank You: AstroNerd, Hy Murveit, Joaquin
Last edit: 3 years 6 months ago by Brian Davis.
3 years 7 months ago #58671

Please Log in or Create an account to join the conversation.

Replied by Jasem Mutlaq on topic Zippity.

Super! Thanks for the guide. I know a few been asking on how to do this! Great job on the write up! But DISCLAIMER use at your own risk!!
3 years 7 months ago #58676

Please Log in or Create an account to join the conversation.

  • Posts: 216
  • Thank you received: 120

Replied by Rick Bassham on topic Zippity.

This is awesome. Note that according to www.raspberrypi.org/documentation/config...n/config-txt/misc.md, max_usb_current is no longer needed, as current firmware sets this by default.
3 years 7 months ago #58699

Please Log in or Create an account to join the conversation.

  • Posts: 1067
  • Thank you received: 140

Replied by AstroNerd on topic Zippity.

Why is the best way to check the speed increase, I have a SSD with it Installed, and an SD card, and want to check the difference...so best way please, ie software to check read and write speeds.... :)
3 years 7 months ago #58703

Please Log in or Create an account to join the conversation.

  • Posts: 348
  • Thank you received: 69

Replied by Giles on topic Zippity.


For disk io may be you can try something like this:

$ dd if=/dev/zero of=/tmp/testfile bs=1G count=1 oflag=direct
1+0 records read
1+0 records written
1073741824 bytes (1,1 GB) copied, 6,9191 s, 155 MB/s

Change the "bs" to something smaller if you're testing slow / small disks.
Make the "of" a file on the filesystem you want to be testing

remember to remove the testfile afterwards
sometimes the /tmp folder is not actually on the disk (e.g. it is a mounted ramdisk), so choose an appropriate location for testing.

You could test read speed by changing "if" to an existing file and "of" to /dev/null
3 years 7 months ago #58704

Please Log in or Create an account to join the conversation.

  • Posts: 1067
  • Thank you received: 140

Replied by AstroNerd on topic Zippity.


Lol....you completely lost me, I am not a coder or do I understand much or what you have written...
Maybe something much simpler... :)
3 years 7 months ago #58707

Please Log in or Create an account to join the conversation.

  • Posts: 348
  • Thank you received: 69

Replied by Giles on topic Zippity.

It is actually not all that complicated.

The dd command, which you type at the command line is just a way of copying data from an input to an output, and it takes various options:

if=/dev/zero

This is the input file (if) and /dev/zero is just a constant stream of zeros, we could have chosen /dev/random, which is a constant string of random characters, but this is slower, and we don't want to slow the process down (as we are trying to measure speed).

of=<some-file-path>

This is the output file, so we just choose a path where we want to put that stream of zeros.

bs=1G

This just says copy 1 Gigabyte of zeros then go to the next count

count=1

We set count to 1, so we will copy 1 x 1G = 1 Gigabyte

oflag=direct

This just says copy the data directly to the destination, without this the data would go into a cache or buffer, and only actually be copied once the system decides there is enough data to sync to disk, so in order to reliably measure the actual speed of the process we bypass that cache/buffer.

The output returned is as follows:

1+0 records read
1+0 records written
1073741824 bytes (1,1 GB) copied, 6,9191 s, 155 MB/s

This says we read and wrote one 1Gigabyte record, it took 6.9191 seconds, so the speed was 155 Megabytes per second.

You can repeat this process to different disks (by changing the of location), and compare the speeds of the operation.
3 years 7 months ago #58713

Please Log in or Create an account to join the conversation.

  • Posts: 216
  • Thank you received: 120

Replied by Rick Bassham on topic Zippity.

I use Ubuntu instead of Raspbian for my setup, so I thought I'd share my instructions for booting from SSD on Ubuntu 20.04.

gist.github.com/rickbassham/bad0a6ef53d567acae5cf6be04d6d7b5

Using an SSD really makes a big difference in how everything performs.
3 years 7 months ago #58717

Please Log in or Create an account to join the conversation.

  • Posts: 33
  • Thank you received: 15

Replied by Brian Davis on topic Zippity.

Had a little free time (ok, I'm retired, so a lot of free time), so I ran some very simple comparisons, with and without the options I posted. Results follow:

All boots on a vanilla Stellarmate 1.5.4 installation, no devices connects (except SSD), and no ad hoc processes running. Just the baseline load.

Using the /dev/zero write command posited by Gilesco:

dd if=/dev/zero of=/home/stellarmate/testfile bs=1G count=1 oflag=direct

SD Card No Overclock
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 92.9448 s, 11.6 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 92.9448 s, 11.6 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 92.9448 s, 11.6 MB/s

SD Card Overclock 1750
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 44.7053 s, 24.0 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 42.4526 s, 25.3 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 42.4526 s, 25.3 MB/s

SSD Only
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.75693 s, 138 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.75693 s, 138 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.75693 s, 138 MB/s

SSD USB3 + Overclock 1750
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.33378 s, 146 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.3983 s, 145 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.3744 s, 146 MB/s

So roughly, the Pi disk IO is 126% faster after the upgrades. Somewhat surprised at the effect overclocking had on disk accesses and writes.

Note: This is just a rough comparison. To be accurate, you'd need to normalize the load on the machine between runs, and copy from one disk to another., etc. But it's a pretty good look regardless. Bear in mind, the overclock and increased IO speed also has marked effects on graphics and general processing speed as well.

I think 12-14 times the speed is reasonably accurate increase expectation. One interesting thing I noticed - allowing a little airspace along the bottom of the Pi makes a significant difference to the temp reported by the SoC. Also, my rig needs to mount on the sprung load portion of the mount, instead of the RA housing, so I need a little DiY work. Next version will be Pi4b 8GB, + NVMe hat + M2 chip + custom case to hold Pi, and USB3 powered hub + larger fan top and bottom (again, Texas heat). Working on the laser cutter drawings now :)

Makes my inner Nerd do the happy dance!

https://media1.tenor.com/images/af5e91f1c822df0a7e8d706cbaa281ed/tenor.gif?itemid=8328248
The following user(s) said Thank You: Giles
Last edit: 3 years 7 months ago by Brian Davis.
3 years 7 months ago #58723

Please Log in or Create an account to join the conversation.

  • Posts: 348
  • Thank you received: 69

Replied by Giles on topic Zippity.

I think I can back up those results, having run SSD rather than SD, with roughly what I experience in real life.

Certainly the overclock seems to produce a big result for the SD card install, not so much with an SSD in terms of % increase, but still a welcome increase.

I've actually tried a couple of power draw reductions (as I may run off battery), they are namely:

Turn off HDMI (VNC still works)

Put the following in /etc/rc.local:

#Turn off HDMI
/opt/vc/bin/tvservice -o

Following /boot/config.txt:
#Disable Wifi (I use a wired connection)
dtoverlay=disable-wifi
#Disable Bluetooth (I don't use Bluetooth)
dtoverlay=disable-bt
#Disable other hardware interfaces (not used in my set up), comment out the lines:
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

Less power draw = less heat, which means that CPU clock will be throttled less if it overheats.
3 years 7 months ago #58724

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226

Replied by Andrew on topic Zippity.

I applied those overclock settings to my Raspberry Pi 4, 4GB running Raspbian Buster 18.04.
over_voltage=6
arm_freq=1750
gpu_mem=256
gpu_freq=600
max_usb_current=1

I thought all was well, but I later found that my Adafruit GPS serial device stopped working. And the culprit was the increase of gpu_freq=600
I don't have a clue how it is at all related. But was fortunate enough to quickly find the issue by undoing the recent change I made.
The following user(s) said Thank You: Spartacus
3 years 6 months ago #59478

Please Log in or Create an account to join the conversation.

  • Posts: 215
  • Thank you received: 41

Replied by Spartacus on topic Zippity.

Hi lhoujin,

Thanks for the warning. I was looking into overclocking the gpu and I have the same GPS so glad I resisted the temptation!
I did come across this overclocking resource.
www.raspberrypi.org/documentation/config...-txt/overclocking.md
It suggests that just changing the gpu_freq in config.txt may result in failure to boot etc.
The relevant section is in the "specific to Pi4B" section.
You might try changing the individual settings as described and see if that lets the GPS be unaffected.
I have decided to leave my gpu alone and just take the gains from arm overclock and SSD boot up.

Cheers

Mike
3 years 6 months ago #59479

Please Log in or Create an account to join the conversation.

Time to create page: 0.909 seconds