SD Card performance in R-Pi onboard slot


290 posts   Page 2 of 12   1, 2, 3, 4, 5 ... 12
by selsinork » Mon Jun 04, 2012 10:13 am
lb, any chance of putting your patches into a github repo ? the bitbucket link doesn't work for me either
Posts: 151
Joined: Mon Apr 16, 2012 8:31 am
by lb » Mon Jun 04, 2012 11:59 am
I'm not really a friend of Github, for the time being get those patches from http://greg.kinoho.net/rpi-sd.tar.gz.

I can't really understand why it's performing so bad for some people. Apparently a certain make of SD cards are problematic with these patches. They always appear at address b368. My Samsung cards appear at address 0002, and work just fine. I don't think mucking with the eMMC clock and setting it far beyond the specs is a good idea. I'd like to make reliable, high-speed transfer modes work on the Raspberry Pi by default, if supported by the card, without any overclocking or hacks.
Last edited by lb on Mon Jun 04, 2012 12:05 pm, edited 1 time in total.
Posts: 193
Joined: Sat Jan 28, 2012 8:07 pm
by AndrewS » Mon Jun 04, 2012 12:03 pm
lb wrote:If you feel adventurous, extract the file, backup and overwrite your current kernel.img, add "init_emmc_clock=100000000" to config.txt and reboot. If everything worked out correctly and your Pi still boots, "hdparm -t /dev/mmcblk0" should now report a sequential read rate of 10 MB/s, or more.

Didn't work for me - does this 'patch' only work for certain classes of SD card? On my Transcend Class6 16GB card your new kernel/config gives me the dreaded "mmc0: error -110 whilst initialising SD card". With the 'standard' kernel from https://github.com/raspberrypi/firmware hdparm gives me read speeds of 4.42 MB/sec.


I did come up with a useful little Bash script for switching kernels though :D
Code: Select all
#!/bin/bash
if [[ $EUID -ne 0 ]]
then
  echo "This tool must be run as root"
  exit 1
fi

if [[ $# -ne 1 ]]
then
  echo "Usage: $0 <config>"
  exit 1
fi
KERNEL=$1
BOOT_PATH=${BOOT_PATH:-"/boot"}

if [[ ! -f "$BOOT_PATH/kernel_$KERNEL.img" ]]
then
  echo "$BOOT_PATH/kernel_$KERNEL.img doesn't exist"
  exit 1
fi
if [[ ! -f "$BOOT_PATH/cmdline_$KERNEL.txt" ]]
then
  echo "$BOOT_PATH/cmdline_$KERNEL.txt doesn't exist"
  exit 1
fi

echo "Switching to $KERNEL kernel"
echo "$KERNEL" > "$BOOT_PATH/.kernel"
cp "$BOOT_PATH/kernel_$KERNEL.img" "$BOOT_PATH/kernel.img"
cp "$BOOT_PATH/cmdline_$KERNEL.txt" "$BOOT_PATH/cmdline.txt"
if [[ -f "$BOOT_PATH/config_$KERNEL.txt" ]]
then
  cp "$BOOT_PATH/config_$KERNEL.txt" "$BOOT_PATH/config.txt"
else
  if [[ -f "$BOOT_PATH/config.txt" ]]
  then
    rm "$BOOT_PATH/config.txt"
  fi
fi
sync
echo "A reboot is needed to activate the new kernel"

Just like rpi-update it has an "offline mode" so that if you switch to a kernel that your Pi is unable to boot, you can simply place the SD card back into your regular Linux PC and run something like "sudo BOOT_PATH=/media/95F5-0D7A/ switch_kernel normal" to restore your "normal" kernel, cmdline and config files.
User avatar
Posts: 3626
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by hojnikb » Mon Jun 04, 2012 4:01 pm
anyone tried this
http://code.google.com/p/flashfire/
on raspberrypi ?

I think it could help with those who have slow 4k write/read.

I was using this driver back on eeepc on winxp and it realy helped, as onboard ssd was not the fastest
+°´°+,¸¸,+°´°~ Everyone should have a taste of UK Raspberry Pie =D ~°´°+,¸¸,+°´°+
Rasberry Pi, SoC @ 1225Mhz :o, 256MB Ram @ 550Mhz, 16GB SD-Card, Raspbian
User avatar
Posts: 112
Joined: Mon Jun 04, 2012 3:59 pm
Location: @Home
by hojnikb » Mon Jun 04, 2012 4:02 pm
http://code.google.com/p/flashfire/
anyone tried to compile this on Pi ?
It suppost to place a small cache betwen drive and OS.
This could possibly help with those who have low 4k reads and writes..
+°´°+,¸¸,+°´°~ Everyone should have a taste of UK Raspberry Pie =D ~°´°+,¸¸,+°´°+
Rasberry Pi, SoC @ 1225Mhz :o, 256MB Ram @ 550Mhz, 16GB SD-Card, Raspbian
User avatar
Posts: 112
Joined: Mon Jun 04, 2012 3:59 pm
Location: @Home
by AndrewS » Mon Jun 04, 2012 5:00 pm
hojnikb wrote:http://code.google.com/p/flashfire/
anyone tried to compile this on Pi ?
It suppost to place a small cache betwen drive and OS.
This could possibly help with those who have low 4k reads and writes..

Hmm... no project updates since December 2010, absolutely no documentation, and there seems to be nothing other than a Makefile and three source files. Doesn't seem very promising... :|

If it does help as you claim, I'd expect to see a bit more activity? Maybe the Linux kernel already contains similar functionality :?: *shrug*
User avatar
Posts: 3626
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by hojnikb » Mon Jun 04, 2012 5:54 pm
Well i can't say for linux version, but with Windows version and with 32MB of cache it really did make a difference for me. I was using it for my eeepc, which has a rather slow ssd without onboard cache so this really helped alot. So i figured it could do the same for pi and slow cards.

Yeah development has ended as dev left and opensourced everything..
+°´°+,¸¸,+°´°~ Everyone should have a taste of UK Raspberry Pie =D ~°´°+,¸¸,+°´°+
Rasberry Pi, SoC @ 1225Mhz :o, 256MB Ram @ 550Mhz, 16GB SD-Card, Raspbian
User avatar
Posts: 112
Joined: Mon Jun 04, 2012 3:59 pm
Location: @Home
by Alfadaz » Mon Jun 04, 2012 7:00 pm
If the read/write to the USB is significantly faster, wouldn't it be more prudent to get the smallest amount of data onto the SD card, then switch to a USB device as soon as possible?

Daz
Posts: 51
Joined: Tue May 22, 2012 10:18 am
Location: Cwmbran, S.Wales
by wartstew » Tue Jun 05, 2012 4:41 pm
I've had my RP for only a day now. :D

I immediately noticed slow I/O speeds to the SD card. :(

I had purchased a class-10 card and verified on a PC that it could pass the “hdparm -t” test at doing about 18 MB/s, yet in the RP it only does ~4.4 – 4.6 MB/s. I guess this means that don't waste your money on anything over a true class 4 -6.

But it gets worse: :cry:

So far the RP has corrupted 3 file systems on two different SD cards. After corruption occurs I did a linux “badblocks -v /dev/sdx” just to see if the SD card was failing and they always passed with flying colors.

I also did a quick test of my power supply, since you probably can't trust the ratings on these cheaply made things. I have two of them and the best one makes 4.8 Volts while plugged in to the RP. I even put an oscilloscope across the big power input capacitor and found that the voltage DID vary perhaps another 0.2V depending on how hard the CPU was working. Looking at the schematics, it appears the only place the raw 5V power is used is for “pull-ups” on the GPIO and HDMI output connectors, none of which I have direct issues with. All other voltages are regulated down to lower voltages using 3 different regulators and the highest one being 3V, this means that I would have to get down to the “drop out” voltage of that regulator before any effect the power supplies lack of good regulation will effect anything.

I also have so far tried two different (actually 3) different images: the Standard Debian one (which I keep trying to update to testing/”Wheezy”, but it ends up being short lived), and the special raspXBMC image (which you install an “installer” image that it then overwrites itself with the latest raspXBMC image). Yet so far the file system eventually corrupts itself.

My question is: Does anyone else have this problem, or is my RP defective?

PS: Due to the slow speed of the SD card slot, I wondering if I can achieve a faster machine doing a network boot, since the network speed seems good (although I haven't actually tested the speed). This would work for me as ultimately I am trying to use this as MythTV “Frontend” for a second TV in the house and I can just as well boot an image from the MythTV backend machine anyway.
Posts: 14
Joined: Mon Jun 04, 2012 11:05 pm
by AndrewS » Tue Jun 05, 2012 7:59 pm
wartstew wrote:I also have so far tried two different (actually 3) different images: the Standard Debian one (which I keep trying to update to testing/”Wheezy”, but it ends up being short lived), and the special raspXBMC image (which you install an “installer” image that it then overwrites itself with the latest raspXBMC image). Yet so far the file system eventually corrupts itself.

My question is: Does anyone else have this problem, or is my RP defective?

Not happened to me yet, but then I've not really 'thrashed' the SD card yet. I'd be tempted to point the finger of blame at your SD card rather than your RPi?

PS: Due to the slow speed of the SD card slot, I wondering if I can achieve a faster machine doing a network boot, since the network speed seems good (although I haven't actually tested the speed). This would work for me as ultimately I am trying to use this as MythTV “Frontend” for a second TV in the house and I can just as well boot an image from the MythTV backend machine anyway.

Uh-huh :) viewtopic.php?f=63&t=5974
User avatar
Posts: 3626
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by LastSilmaril » Thu Jun 07, 2012 10:23 am
This resulted in a regression in speed for me (Transcend 8GB Class 10). Even without doing any measurements it's obvious something is wrong when archlinux takes over a minute to boot. I tried using smaller numbers for init_mmc_clock but that just made things worse...

kernel:
Linux alarmpi 3.1.9-12+ #5 Sat Apr 28 04:49:38 UTC 2012 armv6l ARMv6-compatible processor rev 7 (v6l) BCM2708 GNU/Linux

[root@alarmpi ~]# hdparm -tT /dev/mmcblk0
/dev/mmcblk0:
Timing cached reads: 140 MB in 2.02 seconds = 69.23 MB/sec
Timing buffered disk reads: 14 MB in 3.18 seconds = 4.41 MB/sec

[root@alarmpi ~]# hdparm -tT --direct /dev/mmcblk0
/dev/mmcblk0:
Timing O_DIRECT cached reads: 10 MB in 2.20 seconds = 4.55 MB/sec
Timing O_DIRECT disk reads: 14 MB in 3.07 seconds = 4.55 MB/sec

[root@alarmpi ~]# dd if=/dev/zero of=tempfile bs=1M count=512 conv=fdatasync,notrunc
write: 4.2MBs
[root@alarmpi ~]#dd if=tempfile of=/dev/null bs=1M count=512
read: 4.6MBs



kernel:
Linux alarmpi 3.1.9+ #35 PREEMPT Mon Jun 4 02:22:04 CEST 2012 armv6l ARMv6-compatible processor rev 7 (v6l) BCM2708 GNU/Linux
init_emmc_clock=250000000

[root@alarmpi ~]# hdparm -tT /dev/mmcblk0
/dev/mmcblk0:
Timing cached reads: 130 MB in 2.01 seconds = 64.66 MB/sec
Timing buffered disk reads: 12 MB in 3.39 seconds = 3.54 MB/sec

[root@alarmpi ~]# hdparm -tT --direct /dev/mmcblk0
/dev/mmcblk0:
Timing O_DIRECT cached reads: 8 MB in 2.20 seconds = 3.64 MB/sec
Timing O_DIRECT disk reads: 12 MB in 3.29 seconds = 3.64 MB/sec

[root@alarmpi ~]# dd if=/dev/zero of=tempfile bs=1M count=512 conv=fdatasync,notrunc
write: 3.5MBs
[root@alarmpi ~]# dd if=tempfile of=/dev/null bs=1M count=512
read: 3.7MBs
Posts: 167
Joined: Wed May 09, 2012 8:16 pm
Location: New York, USA
by lewmur » Thu Jun 07, 2012 7:13 pm
I'm having a weird problems with a Super Talent 16gb class 10 card. I set my Pi up to boot from a USB drive using another SD Card and then got the 16gb and wanted to use it for the extra space. I dd'd the same image to it that I used on the other card and made the same change to the cmdline.txt to get it to boot the USB drive. All appeared to be fine except that there was a long delay activating the swap partition during boot. Got to the login screen and the keyboard worked fine to login and type "startx". Now at this time the system is running off of the USB drive, so the SD Card shouldn't make any difference. But it does. After starting X, neither the mouse nor the keyboard work. Unplugging and plugging the back doesn't help.

Anybody have any ideas about what is causing this? BTW, it happens with both LXDE and XFCE4.
Posts: 284
Joined: Sun Dec 25, 2011 3:20 pm
by AndrewS » Sat Jun 09, 2012 2:36 pm
I hate to post another "check the power supply" type question, but maybe the bigger card uses more power? :? Or maybe you need to write a "fresh" image rather than DDing one card to another?
User avatar
Posts: 3626
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by rmm200 » Sat Jun 09, 2012 3:00 pm
Startx was pretty much killing my system (loss of internet, etc.) until I tracked the problem down to a 10 port powered hub.
Switched to a Belkin 4 port hub and all those problems went away.
Posts: 259
Joined: Sat Mar 03, 2012 10:25 pm
by Larry_Adlard » Sun Jun 10, 2012 2:38 pm
lb wrote:Alright, I've applied an upstream fix for proper handling of SD 3.0 cards now, and patched the Broadcom eMMC driver to take advantage of the full clock range. No hacky, nasty clock forcing necessary anymore. Here's the code and I prepared a pre-built, compressed kernel.img.

If you feel adventurous, extract the file, backup and overwrite your current kernel.img, add "init_emmc_clock=100000000" to config.txt and reboot. If everything worked out correctly and your Pi still boots, "hdparm -t /dev/mmcblk0" should now report a sequential read rate of 10 MB/s, or more.

I'm really interested in some feedback, so please test - I've been running with high-speed SD clock for two days now, and everything has been perfectly stable.


OK here's some feedback on the alternative kernel.

I originally used a class4 TDK microSD in adapter while I was waiting for delivery of class 10 Integral ultimaPRO 16GB card. At that time I didn't understand how to measure the speed but the class 10 card seemed significantly faster. I can't recheck because I mislaid the TDK for the moment.

I downloaded the kernelxz. For the benefit of users new to linux this comes in compressed format and it's much easier to move it to a directory on another machine and unpack it. This was then copied to the Card Boot Section again on another machine with a card reader.

I then renamed kernel.img to kernel_old.img. Just as well in the event!

I then renamed kernelxz.img to kernel.img.

Results of the tests: ( "sudo hdparm -t /dev/mmcblk0" )

Original Kernel

14MB in 3.15 secs = 4.44MB/sec

New Kernel xz

Problem initialising card
110 whilst initialising SD
84 whilst initialising SD
110 whilst initialising SD
110 whilst initialising SD
Controller never released status bits.

The system does load after this but the performance is worse.

4MB in 3.38 secs = 1.18MB/sec

I appreciate your efforts but it didn't work for me. :)
User avatar
Posts: 53
Joined: Tue May 29, 2012 8:07 pm
Location: Bradford, West Yorkshire, UK
by lb » Sun Jun 10, 2012 3:33 pm
I'm still not sure why this does not work at all with some cards (but people on IRC were more successful), but for the cards that do work reliably, I've got some more improvements. It turned out that the base clock divisor calculation is incorrect, and introduces a factor of two into the divisor. That means everything is essentially driven at only half the clock it is supposed to run. That's why OP found the SD clock to be limited to 10 MHz, while the kernel was trying to limit it to 20 Mhz. With that fixed, I get about 19 MB/s out of the SDHCI interface, with the eMMC base clock at just 50 MHz, completely within spec.

Anyway, I've uploaded my changes, with added debug output to https://github.com/grigorig/rpi-linux/c ... sdhci-perf. I've also cherry-picked a few commits from upstream that are targetting card compatibility issues, maybe they'll help those people with problematic cards. If you want to test those patches make sure to add "init_emmc_clock=50000000" to config.txt or you'll terribly overclock your SD card. (I'd really like to query the eMMC base clock at runtime, but that does not seem to be easily possible)
Posts: 193
Joined: Sat Jan 28, 2012 8:07 pm
by lb » Sun Jun 10, 2012 4:05 pm
Apparently high speed transfers are what's causing problems with some cards. I've just pushed another change that allows runtime configuration of high speed modes. They're disabled by default and can be enabled by specifying "sdhci-bcm2708.allow_highspeed=1" on the kernel command line. Even without high speed transfers, about 10-11 MB/s can be achieved, and if the card can do it, high speed modes are easily enabled.

Anyway, I've built a ready-to-use kernel image again, download here. Remember to adjust init_emmc_clock if you want to try it. It'd be interesting to know if this works better for you all that have strange issues with the older fixes.
Posts: 193
Joined: Sat Jan 28, 2012 8:07 pm
by calinp » Sun Jun 10, 2012 9:10 pm
Hello lb,
I tested your kernel and it works great!
In Debian i got now:
- 12MB/s without high speed and emmc_clock set to 100 000 000
104857600 bytes (105 MB) copied, 8.14252 s, 12.9 MB/s
- 15MB/s with high speed and emmc_clock set to 50 000 000
104857600 bytes (105 MB) copied, 6.99082 s, 15.0 MB/s

Test performed on 4gb class 4 microSDHC via ssh

Thanks for your hard work!!
Posts: 4
Joined: Fri May 25, 2012 6:45 am
by lb » Mon Jun 11, 2012 12:38 am
I think we need to enable the SDHCI_QUIRK_NO_HISPD_BIT quirk to make those crappy cards work correctly. I've done just that, and cleaned up the whole driver a lot. high-speed mode is now allowed by default, and also works with a card that didn't work at all previously. With a snappy card you should get about 20 MB/s read performance.

The code can be found in my repository and a prebuilt kernel image is available here. Please make sure to set "init_emmc_clock=50000000" in config.txt. This will not work with the default clock of 80 MHz or even higher clocks.

Testing is appreciated, especially if you tried one of my earlier patchsets before and it did not work, or was very slow.
Posts: 193
Joined: Sat Jan 28, 2012 8:07 pm
by reggie » Mon Jun 11, 2012 1:30 am
Fantastic work lb :) I'd like to clear a couple of things up if I may?

1. Your patches have basically set the emmc clock to 50Mhz, this allows the driver to correctly calculate clock speeds and dividers that are in line with the SD spec for 'default and 'high' speed cards. These 2 modes are the only modes that the driver supports.

2. This should give a theoretical max speed of 12.5MB/s and 25MB/s respectively, no matter what class or speed of card.

3. If you have a naturally slow card, this patch won't magically make them any faster but if your card is fast enough you will see a 4-5x speed increase from the stock kernel.

4. Since we are now running the cards in spec, with correct clock speeds, there is zero need for anyone to use emmc_init_clock in their config.txt or if they do there is no point in setting it to anything other than 50Mhz.
Posts: 151
Joined: Fri Aug 26, 2011 11:51 am
by AndrewS » Mon Jun 11, 2012 1:53 am
lb wrote:Testing is appreciated, especially if you tried one of my earlier patchsets before and it did not work, or was very slow.

Wow, awesome work lb!
I've just tried your 20120611 kernel with a 50MHz eMMC clock, and using the same card as previously I now get an hdparm read speed of 18.5MB/s :D
Hopefully (after more testing) Naren will approve your patches and incorporate them into the 'official' RPi firmware kernel 8-)
User avatar
Posts: 3626
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by Larry_Adlard » Mon Jun 11, 2012 2:43 am
Tales of woe. It's been a long day and you can tell by the time of this post that we're coming to the end of it.

First problem. On any other computer the 'boot directory' shows empty. The Rpi must generate these files during the boot process. You can see these on the RPi itself and you can modify "cmdline.txt" to include "sdhci-bcm2708.allow_highspeed=1" but if that screws the system up you have bricked the SD Card. I don't mind being the first to do that; I'm using Imagewriter to re-create the image but for a while it looked as if I would have the dubious distinction of being the first to brick an RPi.

Working backwards, adding "init_emmc_clock=50000000" to config.txt doesn't seem to cause a problem. The new kernel causes an error 84 on the Class 10 SD card.

I managed to locate the Class 4 TDK Micro SD Card (and Adapter). Forgetting the modify "cmdline.txt" to include "sdhci-bcm2708.allow_highspeed=1", I modified it to use the new kernel after checking that the original kernel worked. It's a massive improvement BUT!

Original Kernel

14MB in 3.15 secs = 4.44MB/sec

New Kernel

44MB in 3.15 secs = 13.99/sec

Now comes the BUT. When you load Xwindows (startx) the mouse and keyboard don't work any more.

I'm out of my depth guys. I really want to develop Python for the kids and messing with the system is stopping me. With the original kernel the Class 10 is faster but there's plenty of performance still to be wrung from the Class 4 card. I'm not complaining, this is the development phase but there a way to go before the kids can plug it in and start programming.

I'll try the new patches I've just seen tomorrow. I'm not giving up but it isn't why I'm here.
User avatar
Posts: 53
Joined: Tue May 29, 2012 8:07 pm
Location: Bradford, West Yorkshire, UK
by asb » Mon Jun 11, 2012 7:09 am
Larry_Adlard wrote:Now comes the BUT. When you load Xwindows (startx) the mouse and keyboard don't work any more.


I suspect the kernel is incompatible with your modules. Verify by seeing if you get an error with `sudo modprobe evdev`.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 800
Joined: Fri Sep 16, 2011 7:16 pm
by selsinork » Mon Jun 11, 2012 10:45 am
Wonderful stuff lb !

I'd been looking at that divisor calculation after trying one of your previous patches. Had seen it done differently on another Arasan driver that google found, but without docs wasn't getting anywhere. So quite impressed you've worked it out.

So I have one of those problematic b368 cards, which now gets 19.8 MB/s read speed. I've confirmed with a scope that your driver is running the card at 50Mhz

I get the following, once, early in the boot process, but it's the only odd sd card related message, previously even 'working' kernels give a few mmc related timeouts, -110 or -84 errors before settling down.
Code: Select all
[    8.205137] mmc0: missed completion of cmd 17 DMA (512/512 [1]/[1]) - ignoring it
[    8.205171] mmc0: DMA IRQ 6 ignored - results were reset

I have seen this a few times before, so hopefully it's not related to your changes.

I'll try this out on the various cards I have, but I suspect you've cracked it and that a lot of the sdcard problems will just disappear with your fixes in place.

Strongly suggest that you send a pull request to dom and see if these can get included in the main kernel.
Posts: 151
Joined: Mon Apr 16, 2012 8:31 am
by lb » Mon Jun 11, 2012 11:16 am
selsinork wrote:I get the following, once, early in the boot process, but it's the only odd sd card related message, previously even 'working' kernels give a few mmc related timeouts, -110 or -84 errors before settling down.
Code: Select all
[    8.205137] mmc0: missed completion of cmd 17 DMA (512/512 [1]/[1]) - ignoring it
[    8.205171] mmc0: DMA IRQ 6 ignored - results were reset

I have seen this a few times before, so hopefully it's not related to your changes.


I also get this sometimes (once after boot), at least with one of my cards. I assume it's harmless. In any case, I also got this with the vanilla kernel, so it isn't really related to my changes.

Strongly suggest that you send a pull request to dom and see if these can get included in the main kernel.


I'll clean up, rebase and split up the changes appropriately and then request a pull.
Posts: 193
Joined: Sat Jan 28, 2012 8:07 pm