Raspi 4 Boot problems

The difference may be caused by different software system or by different physical card I/O properties (even if the cards claim to have same speed class)

To ensure identical environments all cards should be written with identical images (not only copies into an existing file system) else comparing boot times may differ due to different settings. Save your actual cards and rewrite all with the same new image, f.e. using Balena Etcher, then check boot times.

If signifcant differences still occure after booting identical systems I would check card I/O times, f.e. using h2testw writing and reading a limited no of files, and check the times needed. h2testw was created to fullfill a drive and to write as many files as possible to fill the drive to check the amount of available space to write, but you can enforce huge file sizes to minimize file creation times.

After that you can see if software system or card I/O genereates a difference, if any.

On Fri, 21 Feb 2020 13:11:48 +0100, "Wendelin Uez" declaimed the following:

Especially if one is comparing Class-10 cards for fragmented file systems.

Classes 2/4/6 were rated for small file creation/deletion, and pretty much random access on fragmented media (still photo cameras, where the user may shoot a batch, delete a few, shoot more...).

Class 10 cards were rated for streaming a large single file onto freshly formatted media (video).

As a result, some Class 10 cards are optimized (cheapened) to only handle the drive allocation bitmap and one open file (FAT file system) while Class 2/4/6 cards could manage multiple open files at the same time. The former cards only buffered two "allocation units" (the chunks that the card maintains, and which must be erased before writing -- bigger than file system clusters/sectors) -- moving from one (output) file to another closes the open allocation unit, finds a free unit, erases it to all 1s, copies the non-affected part of the file system data to it and then writes new data. Multiple unit cards can track the bitmap and more than one active allocation unit without triggering an allocate/erase/copy cycle.

Journaling file systems are deadly on the "optimized" cards -- since one has the bitmap, journal file, data blocks for file, and then the purging of the journal when the OS confirms the file system is up-to-date.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Can one detect such an optimized class 10 card?

On Sat, 22 Feb 2020 19:03:55 +0100, "Wendelin Uez" declaimed the following:

Unless one can obtain detailed specifications for the chip(s) inside the card, I suspect the only means is by benchmarking. Note that many of the lower cost cards are distributed by companies that don't produce chips

-- they contract out with the few chip foundries for a lowest-bid batches, and when they run out of a batch, the next batch of "the same" may come from a different foundry with different behavior.

Unfortunately, the most detailed information source became a dead link a year or so back -- it had a table showing how many allocation units could be held open at once, along with performance on read/write of streams and small random files.

The second source is still alive:

""" Restrictions on open segments

One major difference between the various manufacturers is how many segments they can write to at any given time. Starting to write a segment requires another physical segment, or two in case of a data logging algorithm, to be reserved, and requires some RAM on the embedded microcontroller to maintain the segment. Writing [SSD thrashing] to a new segment will cause garbage collection on a previously open segment. That can lead to thrashing as the drive must repeatedly switch open segments; see the animation behind the diagram to the right for a visualization of how that works.

On many of the better drives, five or more segments can be open simultaneously, which is good enough for most use cases, but some brands can only have one or two segments open at a time, which causes them to constantly go through garbage collection when used with most of the common filesystems other than FAT32.

When a drive reserves the segments specifically to hold the FAT, these will always be open to allow updating it while writing streaming data to other segments. """ {Note the emphasis on FAT file system}

A more recent entry:

(since wear is caused by erase cycles, and cards with a low open allocation count could trigger more erase cycles, such cards will wear faster, and likely be slower in operation). There tool is currently in "public Alpha release" BUT... only appears to work with some of their products (Apalis and Colibri boards) -- pity, as the "block level erase count" monitoring might have shown significant differences between the cards if comparing start and end counts during the image flashing.

An R-Pi specific page -- which includes instructions for duplicating the benchmarks:

""" Most cheap microSD cards, even if rated as being 100MB/sec+ class 10 cards, can?t sustain anywhere near that rate when writing random data?especially on the Raspberry Pi?s measly data bus. (Note that most of the above benchmarks, when run on a USB 3.0 card reader on my MacBook Air, show 5,

10, or 15 times greater performance in that environment). """

{Hmmm, wonder if that benchmark will also run on the BeagleBones}

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

o/~ Talking to myself in public o/~

On Sun, 23 Feb 2020 10:19:08 -0500, Dennis Lee Bieber declaimed the following:

BeagleBone Black SanDisk Edge 8GB Class 4 HC I8227DTJLT009 (no clock speed line) Timing buffered disk reads: 66 MB in 3.06 seconds = 21.54 MB/sec random random kB reclen write rewrite read reread read write 102400 4 2288 195 6249 6246 5289 1211

Raspberry-Pi 3B+ Kingston 16GB Class 10 HC I U1 SDC10G2/16GB N0581-002.A00LF microSD clock: 50.000 MHz Timing buffered disk reads: 66 MB in 3.03 seconds = 21.81 MB/sec random random kB reclen write rewrite read reread read write 102400 4 242 233 5875 5852 5183 234

From iozone listing the "Output is in kBytes/sec"... I don't have the "dd" test results (hadn't realized it wrote to screen, not the redirected output file).

Lets make that easier to compare by running it as columns (and for giggles, the BBB 4GB eMMC). I'm going to rerun (to get "dd" results, and copy the numbers from PuTTY session -- so they may differ some from the above cut&paste; especially as I've run apt update/upgrade just before the reruns).

metric BBB RPi3B+ eMMC bdr-MB 21.74 21.97 hdparm did not run (tried to access SD) dd-sec 89.4367 67.4917 63.8932 dd-MB 4.7 6.2 6.6 write 1652 250 1814 rewrite 2306* 237 1888 read 6371 5814 5039 reread 6375 5798 5038 ranread 5364 5138 3562 ranwrite 1157 234 395

* Hmmm, the "rewrite" test came out 10X the speed of the first time (shown above) that I ran it. Documentation for iozone does state that rewrite is expected to be faster than write, so this may be a correct value.

On the SD cards, the hdparm "buffered disk read" speed is practically the same. I didn't try modifying the script to properly access the eMMC.

The "dd" output shows the SanDisk Class-4 is slower than the Kingston Class-10 and the eMMC -- by about a third.

The iozone output is telling, however. I started the BBB SD card rerun

5 minutes after the R-Pi3B+ and the latter is still running 10 minutes after the BBB finished! *********************************************************************** *********************************************************************** *********************************************************************** That Class-10 Kingston card lost to the Class-4 SanDisk on ALL iozone tests -- the C4 card is 5 to 10 times faster on write, rewrite, and random write tests, and 10% faster on read operations. Even the onboard 4GB eMMC of the BBB was faster on write operations. *********************************************************************** *********************************************************************** ***********************************************************************

For writing streaming data (~"dd") to a single file, the Kingston and eMMC are a close match, and faster than the SanDisk. But overall -- that Class-4 SanDisk is a much better match to operations on a journaling file system such as Linux EXT3/4. When writing to multiple small files (such as logs) the Kingston STINKS. I should write the Pi-Star software to that card and put it into my radio hotspot -- since Pi-Star normally runs as a R/O file-system, putting logs into a RAM disk.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

FWIW, Samsung Evo Plus 64Gb seems to work fine..... SanDisk Extreme Plus 32Gb worked well for over a year. bob prohaska