I cannot get my BBB to use the external micro SD card with decent speeds. I have set up Angstrom on a Sandisk 16GB Class 10. With a USB card reader on Windows I get read speeds of 15-20MB/s and write speeds of 8MB/s. Under Angstrom, hdparm -t returns
/dev/mmcblk0: (SD card)
Timing buffered disk reads: 18 MB in 3.29 seconds = 5.47 MB/sec
/dev/mmcblk1: (internal EMMC)
Timing buffered disk reads: 50 MB in 3.06 seconds = 16.34 MB/sec
I did not find out how to benchmark the write speed without losing data, but from copying a few files it is <1 MB/sec for the micro SD card. Also, it appears that Linux uses write caching on the SD card, and when it decides to flush the buffer it can stall for several seconds due to the slow write speed. What is going on?
I did not find out how to benchmark the write speed without losing data, but from copying a few files it is <1 MB/sec for the micro SD card. Also, it appears that Linux uses write caching on the SD card, and when it decides to flush the buffer it can stall for several seconds due to the slow write speed. What is going on?
Did some reading, and I am pretty sure that there is something fishy with the uSD slot.
To get a clearer picture of what is going on, I wanted to find out if the eMMC is performing at spec.
The datasheet for the Micron eMMC part says that it should be capable of 30MB/s read and 6.6MB/s write. It also states that the part supports DDR mode, which the AM335x parts does not. I’m not sure how non-DDR access affects the speed, but we are getting about half, and we also need to consider real-world overhead from the file-system etc., so that’s probably ok, I don’t know.
The eMMC part is connected to MMC1 on the MPU using the full 8 bit, while the uSD slot is connected to MMC0 at 4 bits.
I then found the Technical Reference Manual for the MPU (document spruh73i.pdf from Texas Instruments) to find out what we should expect from the MMC0 port at 4 bits.
On page 3869 it states:
Clock support
– 96-MHz functional clock source input
– up to 384Mbit/sec (48MByte/sec) in MMC mode 8-bit data transfer
– up to 192Mbit/sec (24MByte/sec) in High-Speed SD mode 4-bit data transfer – up to 24Mbit/sec (3MByte/sec) in Default SD mode 1-bit data transfer
That means it should be possible to reach far better speeds (up to 24 MB/s) from a fast uSD card than we are getting now.
MMC0 and MMC1 ports are independently configured, so I believe it is entirely possible that some register needs to be configured to reach maximum speed.
Now I just need to learn how to read and write those registers.
Ok, sorry I stated the obvious going by what you wrote there ( sorry did not read the whole post first). Anyway, going by what I’ve seen said on these groups, I would not expect too much work in the area of “fixing” this.
you can boot from the eMMC.
you can netboot. ( possible to get 11.9MB/s reads, and 11.1MB/s writes )
you can boot from a USB device.( for me ~20MB/s writes, ~10.6MB/s reads )
Plenty of room there for different purposes, and at least two to avoid wearing out the eMMC( or uSD ). So you could for instance setup a development environment on the BBB, and compile your life away - Just be warned, it will be painfully slow. Example compiling nodejs on the BBB took me around 2 hours. In a virtual machine( Debian ) on a windows host it took 5minutes. ← One CPU 2GB ram.
Anyhow uSD is not going to be long term reliable, this is why I think you wont see much improvement( if any ) in this area.
/dev/mmcblk0:
Timing cached reads: 372 MB in 2.00 seconds = 185.64 MB/sec
Timing buffered disk reads: 16 MB in 3.00 seconds = 5.33 MB/sec
eMMC:
debian@bbb:~$ sudo hdparm -tT /dev/mmcblk1
/dev/mmcblk1:
Timing cached reads: 444 MB in 2.01 seconds = 221.28 MB/sec
Timing buffered disk reads: 42 MB in 3.11 seconds = 13.51 MB/se
On the beaglebone black, it is 'slower' then other mmc implementations
using the same media and a 4bit interface. Probably just the early
nature of the existing mmc code in 3.8 for this hardware... I would
test v3.12, but my Ultra's are all at home..
Robert, I did not mean that as a slight. I am perfectly happy. especially considering I have not contributed to the kernel at all, and it comes at no charge. Granted, I did not use hdparm, I used dd for ~1GB worth of data.
Anyhow . . .
william@arm:~$ sudo hdparm -tT /dev/mmcblk0
/dev/mmcblk0:
Timing cached reads: 382 MB in 2.01 seconds = 190.40 MB/sec
Timing buffered disk reads: 16 MB in 3.09 seconds = 5.18 MB/sec
Bus-width is not the (entire) issue since Raspberry Pi can read 4x faster than BBB with the same cards, also using 4-bit access.
The controllers for the eMMC and the uSD seems to be identical except for bus-width and powercontrol. This suggests that Linux is fully capable of handling the controller.
Going bare metal may be more efficient than Linux, but again the RPi can do 4x the performance using Linux. (unfortunately docs on the RPi controller are not available)
I haven’t tested every linux distro, but performance seems to be more or less identical between different distros.
I know there are ways around the issue (eg. USB), but I think it would be a shame not to use this fantastic device to it fullest potential. It may be silly of me to try to figure this out, but hey, sometimes the journey is the reward
I’ll let you know if I find a solution or a pointer to where the problem might be.
I was referring to the data you posted as it relates the hardware specification of the components in question and your assertion that those numbers could be met with a high level operating system,.
That is all I was saying. And yes, bare metal will be faster as that is all it has to do.
Sorry for not being clear about that. No, I don’t expect full 24MB/s using Linux. I was only trying to argue that nothing in the hardware specs suggests that ~5.6MB/s is the limit for read speed.
Understood. Just to be clear on my end. People read these emails and posts. I don’t want them led into the wrong direction if at all possible, Especially those that may just skim them.
Anyway, now I’m getting somewhere… Luckily the datapins on the uSD connector are exposed while the card is inserted, so I hooked up the oscilloscope, and probed the pins while reading and writing to the uSD card:
Pin 1 (DAT2): No activity (high)
Pin 2 (CD/DAT3): No activity (high)
Pin 3 (CMD): Some activity, varying freq. around 3 KHz
Pin 4 (VDD): High
Pin 5 (CLK): Slight variation around 47 MHz
Pin 6 (VSS): Low
Pin 7 (DAT0): Lots of activity, freq. varying wildly, but mostly around 6-7MHz
Pin 8 (DAT1): No activity (high)
No observable difference between reading and writing.