Raspberry Pi Slowdown

At first, the yard camera worked fine, but a few days later the stream of JPEG images would unpredictably stall. I connect to it through a public-key SSH session and, sometimes, the login would stall for tens of seconds and, with a session set up, various exciting operation like, say, htop would unpredictably stall; if I waited long enough, they’d complete normally.

This seemed familiar:

Samsung 16 GB Evo MicroSD card
Samsung 16 GB Evo MicroSD card

It’s a known-good card from a reputable supplier, not that that means much these days. The camera flash highlights the gritty silkscreen (?) texture of the orange overlay, but the production value seems high enough to pass muster.

Popping the card in my desktop PC showed:

  • It remains functional, at least to the extent of being mount-able and write-able
  • 3probe --time-ops /dev/sdb showed it still held 16 GB
  • fsck -fv /dev/sdb[12] shows no problems
  • Both partitions looked good

So I shrank the main partition to 7.5 GB, copied the image to the desktop PC’s SSD, fired up the Token Windows Laptop, ran the Official SD Card Formatter, and discovered that it thought the card had only 63 MB (yes, MB) available. That’s the size of the FAT boot partition, so I returned the card to the desktop PC, unleashed gparted on it, blew away the partitions, reformatted the whole thing to one 16 GB FAT32 partition, and stuck it back in the laptop, whereupon the Official Formatter agreed it had every byte it should.

A format-with-overwrite then proceeded apace; the card doesn’t support format-with-erase.

Back in the desktop, I copied the saved image back onto the card which, en passant, blew away the just-created FAT format and restored the Raspbian partition structure. The 8 GB of that copy proceeded at an average 12.1 MB/s. I did not watch the transfer closely enough to notice any protracted delays.

Back in the Pi, the card booted and ran perfectly, sending an image every second to the laptop (now running its usual Mint Linux) on the guest network:

Turkey flock in driveway - 2017-03-21
Turkey flock in driveway – 2017-03-21

SSH sessions now work perfectly, too, and commands no longer jam.

So it seems a good-quality MicroSD card can experience protracted delays while writing data, to the extent of tens of seconds, stalling the Pi in mid-operation without producing data errors or any other symptoms.

It’s not clear the Official Formatter does anything that simply copying the image back to the card wouldn’t also accomplish, although overwriting the entire 16 GB extent of the card exercises all the cells and forces the card controller to re/de/un/allocate bad blocks. If, indeed, the blocks are bad, rather than just achingly slow.

Moral of the story: Don’t use MicroSD cards as mass storage devices, at least not for industrial applications that require consistent performance.

6 thoughts on “Raspberry Pi Slowdown

  1. Odd that the formatter pays any attention to partitioning. I’ve had a few cards and drives that have weird boot partitions, and spent a while to find the proper incantation to make something that will work on both windows and real computers. Some situations need MBR, others need a GUID Partitioning Table.

    1. Aye! I’d expect the Official Formatter would extract config data directly from the card hardware and pay no attention to the MBR, but that’s not what happens.

  2. That’s a handsome flock of wild turkeys. What do you feed them?

    1. They’re responsible for their own chow! Minus the snowcover, they harvest bugs & seeds all over the “lawn”. They often scratch the mulch out of the herb plantings along the garden fence over on the left and sometimes taste those leaves; we think of them as self-seasoning turkeys.

  3. In my experience (with uSD for a BeagleBone Black), Windows can only see the first partition – which may explain the 63MB result. That resulted in a non-traditional partitioning scheme which made the first partition the largest, “data” partition.

    1. I’ve stumbled over that gotcha a few times and, at one point, installed a Windows driver making ext2 filesystems available. IIRC, it didn’t work particularly well and didn’t handle the journaling in ext3 filesystems; that was quite a while ago, though.

      In the other direction, the Microsoft ExFAT filesystem, in all its proprietary glory, causes vast heartache & confusion in my Sony HDR-AS30V helmet camera. The camera presents the card as a USB mass storage device, but routinely kills the exfat FUSE driver stone cold dead. Sticking the card directly into a USB reader, however, works perfectly through the same FUSE driver, so that’s what I do now.

Comments are closed.