Re: Clock display on Linux systems?
In this application RPis seem to last for many years - in others where we
use the SD-card (e.g. influxdb or similar) they seem to regularly fail in
1-2 years, requiring an reformat or new SD-card. An RPi or similar with a
more robust SSD/M2 drive would be good.
I’ve had the same experience with the SD cards.
At least the most recent Raspberry Pis (e.g. the 4B) support firmware to boot from USB with just a little configuration effort. I just recently starting playing with this, booting a RPi 4B from a USB-attached Samsung T5 SSD. It seems to work mostly fine (caveat: see below). For other reasons, I’ve been running a RPi-specific version of Linux MATE, but Raspbian should work okay too. (I tried the RPi-specific image of Ubuntu, since I run Ubuntu on my Intel machines, but was not terribly impressed; slow interactive response.)
One thing I did run into: if I try to plug too many USB devices in along with the SSD - e.g. in my case a mouse, keyboard, and GPS dongle - the system crashes because the SSD USB connection resets. It seems to be a power problem; I solved it with an external powered USB hub, leaving the SSD on a USB port on the RPi.
:John
--
J. L. Sloan Digital Aggregates Corporation
+1.303.489.5178 3440 Youngfield Street
mailto:jsloan@diag.com #209
http://www.diag.com Wheat Ridge CO 80033 USA
I forget where I saw it, but my understanding is that the big issue is finding SD cards that can perform whole-disk wear leveling, like proper SSDs do. Apparently, the WD purple series do, according to the e-mail thread I read that I forgot where. Someone contacted WD and got a confirmation that these really do have whole-disk wear leveling. Given that they’re targeting surveillance cameras, it seems reasonable.
On Dec 7, 2021, at 6:09 AM, John Sloan jsloan@diag.com wrote:
In this application RPis seem to last for many years - in others where we
use the SD-card (e.g. influxdb or similar) they seem to regularly fail in
1-2 years, requiring an reformat or new SD-card. An RPi or similar with a
more robust SSD/M2 drive would be good.
I’ve had the same experience with the SD cards.
At least the most recent Raspberry Pis (e.g. the 4B) support firmware to boot from USB with just a little configuration effort. I just recently starting playing with this, booting a RPi 4B from a USB-attached Samsung T5 SSD. It seems to work mostly fine (caveat: see below). For other reasons, I’ve been running a RPi-specific version of Linux MATE, but Raspbian should work okay too. (I tried the RPi-specific image of Ubuntu, since I run Ubuntu on my Intel machines, but was not terribly impressed; slow interactive response.)
One thing I did run into: if I try to plug too many USB devices in along with the SSD - e.g. in my case a mouse, keyboard, and GPS dongle - the system crashes because the SSD USB connection resets. It seems to be a power problem; I solved it with an external powered USB hub, leaving the SSD on a USB port on the RPi.
:John
--
J. L. Sloan Digital Aggregates Corporation
+1.303.489.5178 3440 Youngfield Street
mailto:jsloan@diag.com #209
http://www.diag.com Wheat Ridge CO 80033 USA
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
The sandisk extreme sd cards have an excellent wear leveling algorithm.
KR
On Dec 8, 2021, at 1:26 PM, Nick Sayer via time-nuts time-nuts@lists.febo.com wrote:
I forget where I saw it, but my understanding is that the big issue is finding SD cards that can perform whole-disk wear leveling, like proper SSDs do. Apparently, the WD purple series do, according to the e-mail thread I read that I forgot where. Someone contacted WD and got a confirmation that these really do have whole-disk wear leveling. Given that they’re targeting surveillance cameras, it seems reasonable.
On Dec 7, 2021, at 6:09 AM, John Sloan jsloan@diag.com wrote:
In this application RPis seem to last for many years - in others where we
use the SD-card (e.g. influxdb or similar) they seem to regularly fail in
1-2 years, requiring an reformat or new SD-card. An RPi or similar with a
more robust SSD/M2 drive would be good.
I’ve had the same experience with the SD cards.
At least the most recent Raspberry Pis (e.g. the 4B) support firmware to boot from USB with just a little configuration effort. I just recently starting playing with this, booting a RPi 4B from a USB-attached Samsung T5 SSD. It seems to work mostly fine (caveat: see below). For other reasons, I’ve been running a RPi-specific version of Linux MATE, but Raspbian should work okay too. (I tried the RPi-specific image of Ubuntu, since I run Ubuntu on my Intel machines, but was not terribly impressed; slow interactive response.)
One thing I did run into: if I try to plug too many USB devices in along with the SSD - e.g. in my case a mouse, keyboard, and GPS dongle - the system crashes because the SSD USB connection resets. It seems to be a power problem; I solved it with an external powered USB hub, leaving the SSD on a USB port on the RPi.
:John
--
J. L. Sloan Digital Aggregates Corporation
+1.303.489.5178 3440 Youngfield Street
mailto:jsloan@diag.com #209
http://www.diag.com Wheat Ridge CO 80033 USA
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
SD cards used in dashcams also suffer severe rewriting behaviour. I believe
there are reviews and comparisons covering various makes in this
application.
On Wed, Dec 8, 2021 at 9:30 PM Kevin Rowett kevin@rowett.org wrote:
The sandisk extreme sd cards have an excellent wear leveling algorithm.
KR
On Dec 8, 2021, at 1:26 PM, Nick Sayer via time-nuts <
time-nuts@lists.febo.com> wrote:
I forget where I saw it, but my understanding is that the big issue is
finding SD cards that can perform whole-disk wear leveling, like proper
SSDs do. Apparently, the WD purple series do, according to the e-mail
thread I read that I forgot where. Someone contacted WD and got a
confirmation that these really do have whole-disk wear leveling. Given that
they’re targeting surveillance cameras, it seems reasonable.
On Dec 7, 2021, at 6:09 AM, John Sloan jsloan@diag.com wrote:
In this application RPis seem to last for many years - in others where
we
use the SD-card (e.g. influxdb or similar) they seem to regularly fail
in
1-2 years, requiring an reformat or new SD-card. An RPi or similar
with a
more robust SSD/M2 drive would be good.
I’ve had the same experience with the SD cards.
At least the most recent Raspberry Pis (e.g. the 4B) support firmware
to boot from USB with just a little configuration effort. I just recently
starting playing with this, booting a RPi 4B from a USB-attached Samsung T5
SSD. It seems to work mostly fine (caveat: see below). For other reasons,
I’ve been running a RPi-specific version of Linux MATE, but Raspbian should
work okay too. (I tried the RPi-specific image of Ubuntu, since I run
Ubuntu on my Intel machines, but was not terribly impressed; slow
interactive response.)
One thing I did run into: if I try to plug too many USB devices in
along with the SSD - e.g. in my case a mouse, keyboard, and GPS dongle -
the system crashes because the SSD USB connection resets. It seems to be a
power problem; I solved it with an external powered USB hub, leaving the
SSD on a USB port on the RPi.
:John
--
J. L. Sloan Digital Aggregates Corporation
+1.303.489.5178 3440 Youngfield Street
mailto:jsloan@diag.com #209
http://www.diag.com Wheat Ridge CO 80033 USA
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe
send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe
send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send
an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
You can also set them up so they don’t write to the SD once everything is set. SD’s will last forever like this. Basically read only and RAM disk.
Bill Dailey
Negativity always wins the short game. But positivity wins the long game. - Gary Vaynerchuk
Don’t be easy to understand,
Be impossible to misunderstand
- Steve Sims
On Dec 8, 2021, at 3:27 PM, Nick Sayer via time-nuts time-nuts@lists.febo.com wrote:
I forget where I saw it, but my understanding is that the big issue is finding SD cards that can perform whole-disk wear leveling, like proper SSDs do. Apparently, the WD purple series do, according to the e-mail thread I read that I forgot where. Someone contacted WD and got a confirmation that these really do have whole-disk wear leveling. Given that they’re targeting surveillance cameras, it seems reasonable.
On Dec 7, 2021, at 6:09 AM, John Sloan jsloan@diag.com wrote:
In this application RPis seem to last for many years - in others where we
use the SD-card (e.g. influxdb or similar) they seem to regularly fail in
1-2 years, requiring an reformat or new SD-card. An RPi or similar with a
more robust SSD/M2 drive would be good.
I’ve had the same experience with the SD cards.
At least the most recent Raspberry Pis (e.g. the 4B) support firmware to boot from USB with just a little configuration effort. I just recently starting playing with this, booting a RPi 4B from a USB-attached Samsung T5 SSD. It seems to work mostly fine (caveat: see below). For other reasons, I’ve been running a RPi-specific version of Linux MATE, but Raspbian should work okay too. (I tried the RPi-specific image of Ubuntu, since I run Ubuntu on my Intel machines, but was not terribly impressed; slow interactive response.)
One thing I did run into: if I try to plug too many USB devices in along with the SSD - e.g. in my case a mouse, keyboard, and GPS dongle - the system crashes because the SSD USB connection resets. It seems to be a power problem; I solved it with an external powered USB hub, leaving the SSD on a USB port on the RPi.
:John
--
J. L. Sloan Digital Aggregates Corporation
+1.303.489.5178 3440 Youngfield Street
mailto:jsloan@diag.com #209
http://www.diag.com Wheat Ridge CO 80033 USA
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
On 12/8/21 2:15 PM, Bill Dailey wrote:
You can also set them up so they don’t write to the SD once everything is set. SD’s will last forever like this. Basically read only and RAM disk.
yes indeed - these days, with lots o'RAM on a rPi, you should boot off
the SD (or eMMC) and run out of RAM. For a "clock" application, you
could probably structure your writes to SD (for nonvolatile storage of
logs, etc.) so that you limit the number of writes. If you log once an
hour that's just under 9000 writes/year.
Typical MLC flash is good for at least 10,000 erase cycles on a page.
Writing data to an erased page (or the part that's not already written)
doesn't wear it out, but changing data in the middle of a file does,
because you have to erase it (consuming life), and then rewrite.
There are Journaling File Systems that deal with this, but I doubt
they're compatible with the wear leveling systems in commercial SD
cards. Basically, the SD card has a controller that exposes a
generalized interface, with the wear leveling hidden from you, and if
it's hidden, then the JFS doesn't really know how to manage the device.
I don't know, though, it's a fertile ground - and someone may have a
nice JFS for a common distro for RPi and SD card.
If you want to get real down and dirty, there are also clever schemes
that write all ones or zeros (depending on the device), instead of
erasing, and then the reader of the file knows that this means "not
used" - Much like the RUBOUT character on paper tape, or a similar
scheme used with PROMS where you don't want to erase it.
Jim,
The wear leveling algorithms have gotten very good at garbage collection, wear leveling, and bit error recovery codes. (LDPC has gotten a lot of practical research for flash).
(the challenges are - when to do the garage collection, so as not to impact read and write rates, yet not run so low that write IOP rate falls off a cliff, AND still keep pages alive).
File systems that try to understand the flash sectors generally haven’t proven as helpful as the flash device controller wear leveling algorithms.
A lot of the SD cards have gone to TLC style memory (also know as trash).
KR
On Dec 8, 2021, at 2:35 PM, Lux, Jim jim@luxfamily.com wrote:
On 12/8/21 2:15 PM, Bill Dailey wrote:
You can also set them up so they don’t write to the SD once everything is set. SD’s will last forever like this. Basically read only and RAM disk.
yes indeed - these days, with lots o'RAM on a rPi, you should boot off the SD (or eMMC) and run out of RAM. For a "clock" application, you could probably structure your writes to SD (for nonvolatile storage of logs, etc.) so that you limit the number of writes. If you log once an hour that's just under 9000 writes/year.
Typical MLC flash is good for at least 10,000 erase cycles on a page. Writing data to an erased page (or the part that's not already written) doesn't wear it out, but changing data in the middle of a file does, because you have to erase it (consuming life), and then rewrite.
There are Journaling File Systems that deal with this, but I doubt they're compatible with the wear leveling systems in commercial SD cards. Basically, the SD card has a controller that exposes a generalized interface, with the wear leveling hidden from you, and if it's hidden, then the JFS doesn't really know how to manage the device.
I don't know, though, it's a fertile ground - and someone may have a nice JFS for a common distro for RPi and SD card.
If you want to get real down and dirty, there are also clever schemes that write all ones or zeros (depending on the device), instead of erasing, and then the reader of the file knows that this means "not used" - Much like the RUBOUT character on paper tape, or a similar scheme used with PROMS where you don't want to erase it.
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
piCorePlayer aka. pCP, a DIY high quality audio player for Squeezelite
are running entirely in RAM after loading from SD card. Only
configuration changes are written to SD card. I have been running a
handful of these devices daily for years on cheap SD cards without any
SD card problems.
The pCP are based on piCore Linux which is a Rasperry Pi port of the
Tiny Core Linux. See the following links for further information on how
to implement and use these Linux ports.
Ref. piCore Linux:
https://iotbytes.wordpress.com/picore-tiny-core-linux-on-raspberry-pi/
https://github.com/mxmxmx/terminal_tedium/wiki/piCore
and Tiny Core Linux:
http://tinycorelinux.net/book.html
http://forum.tinycorelinux.net/index.php
Regards,
Per
On 08.12.2021 23:35, Lux, Jim wrote:
On 12/8/21 2:15 PM, Bill Dailey wrote:
You can also set them up so they don’t write to the SD once
everything is set. SD’s will last forever like this. Basically read
only and RAM disk.
yes indeed - these days, with lots o'RAM on a rPi, you should boot off
the SD (or eMMC) and run out of RAM. For a "clock" application, you
could probably structure your writes to SD (for nonvolatile storage of
logs, etc.) so that you limit the number of writes. If you log once an
hour that's just under 9000 writes/year.
Typical MLC flash is good for at least 10,000 erase cycles on a page.
Writing data to an erased page (or the part that's not already
written) doesn't wear it out, but changing data in the middle of a
file does, because you have to erase it (consuming life), and then
rewrite.
There are Journaling File Systems that deal with this, but I doubt
they're compatible with the wear leveling systems in commercial SD
cards. Basically, the SD card has a controller that exposes a
generalized interface, with the wear leveling hidden from you, and if
it's hidden, then the JFS doesn't really know how to manage the device.
I don't know, though, it's a fertile ground - and someone may have a
nice JFS for a common distro for RPi and SD card.
If you want to get real down and dirty, there are also clever schemes
that write all ones or zeros (depending on the device), instead of
erasing, and then the reader of the file knows that this means "not
used" - Much like the RUBOUT character on paper tape, or a similar
scheme used with PROMS where you don't want to erase it.
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe
send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
--
E-posten er sjekket for virus av AVG.
http://www.avg.com
I don't recommend USB as a highly reliable boot device for Linux. I did
development and support on a Linux based embedded product that kept all its
nonvolatile storage on a USB drive on an eUSB card inside the case, a lower
cost alternative to SSD or PCIe based drives. While it worked on about 99%
of the boots if I did my best engineering work, if a keyboard, mouse, or
other USB device was connected to one of the external USB ports, I could
easily generate enough USB traffic to cause the boot to fail while the Grub
bootloader was running - resulting in it corrupted reads of the kernel or
initial ramdisk image from the eUSB drive. I suspect that Grub's drivers
are pretty naive about what might happen and assumes no other active
devices on the bus. We also tried many different USB storage devices from
vendors which were either unprepared to be boot devices at all, were
unprepared for other devices coming online/offline or other enumeration
activities while they were doing work, fine with FAT but not ext2/ext4
filesystems, or prone to corrupting their own firmware or translation layer
database when they became confused. When it came time to replace the PC I
specified one with eSATA internal storage and all these problems went away;
plus, the drive had S.M.A.R.T. so could self-monitor and report its health
(whereas all the USB products had few if any statistics and just got more
broken with time).
Time related: this embedded product had a controlling PC and 27 ARM
application processors which used USB for coordination and booted using IP
over USB. Since the ARM processors were running in an environment and
hardware I had total control over, I could make USB work relatively
reliably there. I used the ISC NTP server to synchronize clocks from the
network NTP servers to the PC and then on to its internal IP network of ARM
Linux systems; also, I used the Time Zone database on the PC and standard
GNU glibc interfaces to that; along the way I found a bug in strptime(3),
which parses TimeZone fields in text strings, e.g. "+08:00", observed it
was broken in several ways, including not working for Time Zones more than
+2300 or -2300, which New Zealand, Kritimati and American Samoa wrestle
with at least seasonally, and some historical places experienced
continuously for years. I proposed a fix to support -99:59 to +99:59 the
libc development list, and it was accepted. This was several years ago.
Cheers,
James
On Tue, Dec 7, 2021 at 6:10 AM John Sloan jsloan@diag.com wrote:
In this application RPis seem to last for many years - in others where we
use the SD-card (e.g. influxdb or similar) they seem to regularly fail in
1-2 years, requiring an reformat or new SD-card. An RPi or similar with a
more robust SSD/M2 drive would be good.
I’ve had the same experience with the SD cards.
At least the most recent Raspberry Pis (e.g. the 4B) support firmware to
boot from USB with just a little configuration effort. I just recently
starting playing with this, booting a RPi 4B from a USB-attached Samsung T5
SSD. It seems to work mostly fine (caveat: see below). For other reasons,
I’ve been running a RPi-specific version of Linux MATE, but Raspbian should
work okay too. (I tried the RPi-specific image of Ubuntu, since I run
Ubuntu on my Intel machines, but was not terribly impressed; slow
interactive response.)
One thing I did run into: if I try to plug too many USB devices in along
with the SSD - e.g. in my case a mouse, keyboard, and GPS dongle - the
system crashes because the SSD USB connection resets. It seems to be a
power problem; I solved it with an external powered USB hub, leaving the
SSD on a USB port on the RPi.
:John
--
J. L. Sloan Digital Aggregates Corporation
+1.303.489.5178 3440 Youngfield Street
mailto:jsloan@diag.com #209
http://www.diag.com Wheat Ridge CO 80033 USA
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send
an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
--
James Perkins james@loowit.net KN1X www.loowit.net/~james
2030 W 28th Ave, Eugene OR 97405 +1.971.344.3969 mobile
Alternate email: opalmirror@gmail.com
You can also use the 'f2fs' as filesystem on your sd-card.
Things become rather slow (as it is a logging filesystem) but I used the
same card for more over 5 years in a frontdoorcamerasystem I wrote and
made.
On Wed, Dec 08, 2021 at 02:43:47PM -0800, Kevin Rowett wrote:
Jim,
The wear leveling algorithms have gotten very good at garbage collection, wear leveling, and bit error recovery codes. (LDPC has gotten a lot of practical research for flash).
(the challenges are - when to do the garage collection, so as not to impact read and write rates, yet not run so low that write IOP rate falls off a cliff, AND still keep pages alive).
File systems that try to understand the flash sectors generally haven???t proven as helpful as the flash device controller wear leveling algorithms.
A lot of the SD cards have gone to TLC style memory (also know as trash).
KR
On Dec 8, 2021, at 2:35 PM, Lux, Jim jim@luxfamily.com wrote:
On 12/8/21 2:15 PM, Bill Dailey wrote:
You can also set them up so they don???t write to the SD once everything is set. SD???s will last forever like this. Basically read only and RAM disk.
yes indeed - these days, with lots o'RAM on a rPi, you should boot off the SD (or eMMC) and run out of RAM. For a "clock" application, you could probably structure your writes to SD (for nonvolatile storage of logs, etc.) so that you limit the number of writes. If you log once an hour that's just under 9000 writes/year.
Typical MLC flash is good for at least 10,000 erase cycles on a page. Writing data to an erased page (or the part that's not already written) doesn't wear it out, but changing data in the middle of a file does, because you have to erase it (consuming life), and then rewrite.
There are Journaling File Systems that deal with this, but I doubt they're compatible with the wear leveling systems in commercial SD cards. Basically, the SD card has a controller that exposes a generalized interface, with the wear leveling hidden from you, and if it's hidden, then the JFS doesn't really know how to manage the device.
I don't know, though, it's a fertile ground - and someone may have a nice JFS for a common distro for RPi and SD card.
If you want to get real down and dirty, there are also clever schemes that write all ones or zeros (depending on the device), instead of erasing, and then the reader of the file knows that this means "not used" - Much like the RUBOUT character on paper tape, or a similar scheme used with PROMS where you don't want to erase it.
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
Folkert van Heusden
--
www.vanheusden.com/multitail - multitail is tail on steroids. multiple
windows, filtering, coloring, anything you can think of
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com