SD Card performance in R-Pi onboard slot


280 posts   Page 7 of 12   1 ... 4, 5, 6, 7, 8, 9, 10 ... 12
by rgh » Sat Jun 16, 2012 8:20 pm
@lb

That seems to have fixed it, thanks! This is the debug output after writing a 64MB file a few times:

[ 223.800146] mmc0: waited 78330 us for SD card
[ 293.486480] mmc0: waited 77970 us for SD card
[ 306.733838] mmc0: waited 73320 us for SD card
[ 330.176607] mmc0: waited 78270 us for SD card
Posts: 220
Joined: Fri Nov 25, 2011 3:53 pm
by lb » Sat Jun 16, 2012 8:34 pm
@rgh

Alright, great. That is definitely dangerously close to the old limit of 100ms. I think raising the timeout to 150ms makes sense.

@dom

I've pushed a commit for this to sdhci-perf-cleanup.
Posts: 193
Joined: Sat Jan 28, 2012 8:07 pm
by bootc » Sun Jun 17, 2012 9:07 am
Folks - I'm just working on a 3.2.20 kernel and I really want to include these SD patches. Can anyone point me to where the latest and greatest patches are for me to include?

Thanks,
Chris
Posts: 19
Joined: Mon May 28, 2012 7:45 pm
by dom » Sun Jun 17, 2012 9:16 am
@lb
Thanks, I've pushed your timeout fix (rpi-update will get it).

@bootc
lb has provided a clean set of sdcard patched here:
https://github.com/grigorig/rpi-linux/c ... rf-cleanup
I've picked up all the patches from this branch, so I'd think it sensible for you to do so to.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3992
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by bootc » Sun Jun 17, 2012 9:20 am
dom wrote:lb has provided a clean set of sdcard patched here:
https://github.com/grigorig/rpi-linux/c ... rf-cleanup
I've picked up all the patches from this branch, so I'd think it sensible for you to do so to.


Thanks. Expect to see a new kernel from me soon! :-)
Posts: 19
Joined: Mon May 28, 2012 7:45 pm
by lb » Sun Jun 17, 2012 12:05 pm
bootc wrote:Thanks. Expect to see a new kernel from me soon! :-)


Careful, that branch doesn't apply cleanly, and it's missing an important patch. I've ported the changes over to the 3.2 kernel and added selsinork's fix for signaling voltage, it's in the rpi-3.2.19-sdhci branch.
Posts: 193
Joined: Sat Jan 28, 2012 8:07 pm
by bootc » Sun Jun 17, 2012 12:18 pm
lb wrote:Careful, that branch doesn't apply cleanly, and it's missing an important patch. I've ported the changes over to the 3.2 kernel and added selsinork's fix for signaling voltage, it's in the rpi-3.2.19-sdhci branch.


Thanks. I'll use your branch instead.
Posts: 19
Joined: Mon May 28, 2012 7:45 pm
by ajack » Sun Jun 17, 2012 3:14 pm
Is anybody maintaining a website or specific link for kernel update?
Posts: 2
Joined: Fri Jun 08, 2012 5:13 am
by bootc » Sun Jun 17, 2012 4:41 pm
Thought I'd best keep you folks posted:
http://www.bootc.net/archives/2012/06/1 ... 20-kernel/
Posts: 19
Joined: Mon May 28, 2012 7:45 pm
by nicknml » Sun Jun 17, 2012 6:29 pm
Does anybody have a personal favorite 16gb card? Right now I'm looking at this one , http://www.amazon.com/Transcend-Class-Flash-Memory-TS16GSDHC10E/dp/B003VNKNEQ/ref=sr_1_1?ie=UTF8&qid=1339957301&sr=8-1&keywords=transcend+16+gb I know that the TS16GSDHC6 version is listed as good on the SD compatibility card page, but it's sold though a 3rd party seller and I like amazon's no-hassle returns.
User avatar
Posts: 195
Joined: Thu Mar 15, 2012 8:44 pm
by pjc123 » Mon Jun 18, 2012 12:50 pm
I know that the TS16GSDHC6 version is listed as good on the SD compatibility card page, but it's sold though a 3rd party seller and I like amazon's no-hassle returns.

I have that exact same card arriving today. It is not only mentioned as a compatible card on the wiki, but several people have reported success right off the bat in the forums as well. That is why I chose it..... So I don't throw another wrench into any troubleshooting I have to do for problems that come up while getting the pi up and running for the first time; and there are plenty of those (Is my power supply well regulated enough, is the power cord high enough quality, will I need a hub for my keyboard and wifi, etc.). The loss of of aggravation of adding an SD card that is tested by multiple people is well worth any return problems that I might have. Once a stable kernel / firmware is released regarding all these SD card issues I will upgrade to a faster card if one comes along since I plan on loading different operating systems on different cards anyway.
Posts: 910
Joined: Thu Mar 29, 2012 3:37 pm
by milhouse » Mon Jun 18, 2012 1:56 pm
I did notice this 32GB Class 4 Transcend for £12 which seems like quite a good deal - not on the "working" list (but perhaps more importantly, not on the "non-working" list either) although as it's a Transcend they seem to have a pretty good track record.
Posts: 552
Joined: Mon Jan 16, 2012 12:59 pm
by anthonyUK » Mon Jun 18, 2012 2:53 pm
An interesting point on the Transcend class6 cards is that the 8gb appears to have twice the write speed of the 4gb and 16gb cards

http://ec.transcendusa.com/product/Item ... TS16GSDHC6

I've just ordered one of the above and will test this evening.
Posts: 27
Joined: Tue May 29, 2012 8:18 am
by AndrewS » Mon Jun 18, 2012 3:42 pm
ajack wrote:Is anybody maintaining a website or specific link for kernel update?

Recommendation is to update using https://github.com/Hexxeh/rpi-update

rpi-update gets its updates from https://github.com/Hexxeh/rpi-firmware which itself is just a trimmed-down version of the official https://github.com/raspberrypi/firmware
User avatar
Posts: 2869
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by ajack » Tue Jun 19, 2012 6:31 am
Is the kernel 3.1.9 going to be updated with the latest SD card patches? I know it has been done on a 3.2 kernel, but that breaks omxplayer. :(
Posts: 2
Joined: Fri Jun 08, 2012 5:13 am
by rew » Tue Jun 19, 2012 7:32 am
lb, you're not programming for some cards some of the time, but for ALL cards ALL of the time.

This means that if a card happens to have to do a refresh or something like that, it may take some time before it gets to your write. Next the write may detect errors, causing a retry, again errors, so now the data has to be remapped. The "whatever it was doing before" can also hit such a problem.

All this is very unlikely. You can't cause it to happen. But in times of "difficulties" you should let the card do its thing and not timeout before it has has had a chance to fix things.

There are definitvely drivers in Linux that timeout too quickly. A harddisk having trouble will sometimes initiate a recovery procedure that takes more than a minute. Linux times out and resets the drive after 30 seconds. The manufacturer decided that it was useful to keep on trying that second half-minute. So why try to outsmart them??

I HAVE seen harddisks that would reliably read every block, but only after several seconds. I'm guessing that the parameters of the read-head have "shifted" over time, so that a new parameter set was necessary. So after getting a read error a few retries take maybe half a second. Then the firmware starts a recovery procedure that includes recalibrating the head position, trying to use the ECC, but finally it will also try to vary some of the read-head-parameters. In that case that was always succesful. And apparently always in a similar phase of the recovery procedure, so it was taking a lot of time.

Now, we, with brains, would say: then why not try "with the parameters that worked on the previous block" after the original-parameter-read fails on the next block. That would lead to a block read every 8 revolution. MUCH better than a block per 4 seconds. Alas, the firmware wasn't written that way. Probably the guys writing the firmware didn't think of this situation.

Oh, PS: My new kernel works and gets 18Mb/sec read performance. Sandisk ultra II 4Gb. (Class 2), printing on the card suggests 15Mb/sec.
Check out our raspberry pi addons: http://www.bitwizard.nl/catalog/
User avatar
Posts: 396
Joined: Fri Aug 26, 2011 3:25 pm
by rurwin » Tue Jun 19, 2012 8:11 am
Coming in late here, and tl;dr 6 of 7 pages, but I do know serial/network protocol drivers as I have been programming them for over 20 years. In all that time I have often been asked to extend a timeout or to provide the facilities to extend them. I have never ever been asked to shorten one*.

Unless it is a published feature of the protocol, (ack-only for example,) it is highly unlikely that a timeout will fix a problem without making it worse. The reason for having timeouts is not to recover the protocol, it is so you have some chance of recovering something from the mess and preventing anything more disappearing down the pan. But it purposely de-synchronises the protocol; from there on the master does not know what state the slave is in and vice-versa. It is not possible to continue as if nothing has happened; you need to re-sychronise, maybe re-initialise, maybe repair damage caused by the fault, and then finally re-try the transaction that caused the fault. All that takes time, a lot of it, and it can corrupt and lose data.

It follows that hitting a timeout should be a last resort. There should be no conceivable chance that a situation is still recoverable when the timeout is triggered. Timeouts should not be set anywhere near the normal operating point. They should be as far away as practical.

So rather than 150 milliseconds, I would be asking what was so terrible about 1 second (or even 3). It will take at least that long to recover if the timeout triggers, and the user is not likely to notice any difference.


-----
* There was one that annoyed me, but it was 60 seconds, which was rather long to wait and I think I eventually took it down to 20. Still, nobody ever asked me to shorten it.
Last edited by rurwin on Tue Jun 19, 2012 8:27 am, edited 1 time in total.
User avatar
Forum Moderator
Forum Moderator
Posts: 2902
Joined: Mon Jan 09, 2012 3:16 pm
by asb » Tue Jun 19, 2012 8:17 am
ajack wrote:Is the kernel 3.1.9 going to be updated with the latest SD card patches? I know it has been done on a 3.2 kernel, but that breaks omxplayer. :(


Yes, the patches were merged and the current build at github.com/raspberrypi/firmware includes them.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 788
Joined: Fri Sep 16, 2011 7:16 pm
by selsinork » Tue Jun 19, 2012 8:18 am
rew wrote:lb, you're not programming for some cards some of the time, but for ALL cards ALL of the time.

Seriously ? lb's driver is much better than the original. Wider exposure to many more cards can only help improve it, but you can never deal with everything - especially a card that hasn't been designed yet and won't be in users hands until a year from now but has some behaviour that's different.

rew wrote:All this is very unlikely. You can't cause it to happen. But in times of "difficulties" you should let the card do its thing and not timeout before it has has had a chance to fix things.

Again, that's fine, up to a point. But sooner or later you need to decide the cards got itself confused, is actually dead, or the user has removed it, it's not going to talk to us again, ever, and timeout.

rew wrote:A harddisk having trouble will sometimes initiate a recovery procedure that takes more than a minute. Linux times out and resets the drive after 30 seconds. The manufacturer decided that it was useful to keep on trying that second half-minute. So why try to outsmart them??

Go buy an 'enterprise' drive, they give up and timeout in seconds. They then return the error to the OS that actually has the smarts to do something about it instead of freezing the system for a minute. Google for people using desktop class drives in NAS devices with raid for lots of details on how pointless that minute long recovery procedure is. Then think about the manufacturer protecting the margins on it's expensive enterprise drives by a simple firmware mod to the otherwise identical desktop drive to prevent it's use for certain things.
Little to do with outsmarting the drive, lots to do with money.
Posts: 151
Joined: Mon Apr 16, 2012 8:31 am
by lb » Tue Jun 19, 2012 10:48 am
rurwin wrote:It follows that hitting a timeout should be a last resort. There should be no conceivable chance that a situation is still recoverable when the timeout is triggered. Timeouts should not be set anywhere near the normal operating point. They should be as far away as practical.

So rather than 150 milliseconds, I would be asking what was so terrible about 1 second (or even 3). It will take at least that long to recover if the timeout triggers, and the user is not likely to notice any difference.


The terrible thing is that currently the driver does busy-waiting until the timeout runs out, if the card is slow. Continually freezing the whole system for up to 3 seconds (in the worst case) wouldn't be a good idea. There's a better solution to this, but it isn't trivial. I'm already looking at it, though.
Posts: 193
Joined: Sat Jan 28, 2012 8:07 pm
by dom » Tue Jun 19, 2012 10:54 am
@lb

Any thoughts on the:
[ 21.317631] mmc0: missed completion of cmd 17 DMA (512/512 [1]/[1]) - ignoring it
[ 21.331364] mmc0: DMA IRQ 6 ignored - results were reset

do you believe it to be harmless?
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3992
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by lingon » Tue Jun 19, 2012 7:36 pm
lb wrote:lingon, what kernel and firmware version are you using for the UHS-1 card? How does booting fail (at what stage, and if applicable, what kinds of errors)?

If you used the Wheezy image as-is, a manual update of kernel and firmware might help.


Today I upgraded to the Debian Wheezy Beta
uname -a
Linux raspberrypi 3.1.9+ #125 PREEMPT Sun Jun 17 16:09:36 BST 2012 armv6l GNU/Linux
This image works fine on the Transcend 8 GB card, but the SanDisk Extreme Pro 16 GB UHS-1 SDSDXP1-016G-X46 card still fails to boot from the very same image. With this new image the OK light turns green when trying to boot from the UHS-1 card. This is some progress compared to the previous Wheezy Alpha version.

My card lacks a Class 10 marking as in this picture
http://veikals.bfs.lv/images/thumbs/def ... 6g-x46.jpg

The similar SanDisk Extreme 16 GB UHS-1 card does have a Class 10 marking in addition to the UHS-1 marking.
http://www.memorycow.co.uk/image/cache/ ... 50x250.jpg

I don't know if the lack of a Class 10 marking is a problem or not. My UHS-1 card works fine with my SD-card reader though.
Posts: 101
Joined: Fri Aug 26, 2011 7:31 am
by n0mad » Wed Jun 20, 2012 9:32 am
cmd 17 seems to be a channel reset.

When DMA fails to confirm a cmd has completed... It usually resets.
tl;dr: failed a reset? reset!

Safe to ignore... I should say yes but I can't. Errors are ugly, they must be corrected. But it shouldn't wreak havoc with the fs or damage the cards.

Also, 3 seconds on a timeout, not that long. Patience is like a beard. Critical for a successful IT career. Bump the timeout, make the firmware conform to the specs, most cards will never hit that 3 sec timeout so I cant imagine there would be a lot of waiting going on. Just my opinion, disregard at will.

Happy to do any firmware testing you'd like, I have 3 cards that reliably issue this error. PM me. I practically live on this board. I'm building a fort in the corner, see --> | | roof goes on soon as I find a suitable blanket.
Posts: 2
Joined: Fri Jun 15, 2012 9:00 am
by lb » Wed Jun 20, 2012 1:14 pm
dom wrote:[ 21.317631] mmc0: missed completion of cmd 17 DMA (512/512 [1]/[1]) - ignoring it
[ 21.331364] mmc0: DMA IRQ 6 ignored - results were reset


I think it's harmless. CMD17 is a single-block read. This is seldom used, and maybe the command simply finishes too quickly for the controller.
Posts: 193
Joined: Sat Jan 28, 2012 8:07 pm
by pjc123 » Wed Jun 20, 2012 8:48 pm
I just installed the wheezy image on my Transcend TS16GSDHC6.

My read speed went from 4.40 MB/sec on squeeze to 18.30 MB/sec with wheezy. Now my old Pentium 4 computer isn't ridiculously faster than the pi, just considerably faster !
Posts: 910
Joined: Thu Mar 29, 2012 3:37 pm