Oh, that might be it. Now I remember which controllers we ran out of - the MMC/SD controllers. One went to the eMMC storage, the other to the WiFi module.
3 Likes
FYI looking at an actual Librem 5, in software, I would say that the following are on the other USB
- uSD card reader
- modem card
- (maybe) Bluetooth
not WiFi.
If Bluetooth is on there then it certainly can’t use USB 3.0 speeds anyway.
The WiFi/BT in the Librem 5 is using SDIO and I2S, but there are also two lines (USB2_WIFI_DP and USB2_WIFI_DN) between the USB2642 and M.2 slot for the WiFi/BT card. Maybe those two USB lines aren’t used, but I assume that Purism connected them for some reason. Maybe Purism is keeping the possibility open for future WiFi/BT cards that need USB, or maybe Purism thinks that people will want to use other types of cards.
Since the USB2642 contains a USB hub, I wonder if Purism could have found a similar chip that supports USB 3.0 to allow high speed access to the microSD card, and then run its USB hub at USB 2.0 speed to connect to the cellular modem.
1 Like
Both.
Since it’s modular (removable), as far as is reasonable, Purism shouldn’t restrict what M.2 card the customer can put in (although I would suppose that anything that uses PCIe / SATA via M.2 may never work e.g. even if you could find an M.2 storage device that physically fitted, it wouldn’t work).
Some customers may want a WiFi card that does not do Bluetooth. Some customers may have no need for either.
With the speeds I am seeing at the moment, I would be happy to see anything like realistically achievable USB 2.0 speeds, never mind about USB 3.0.
It would be cool if someone would do some benchmarking of the Librem 5’s microSD, using hdparm and dd, as described in this article and this one. It might give us some idea whether the USB bus is the limiting factor. For example, if the read speeds are 15 MB/s on a card that supports 50 MB/s, then the USB bus is probably not the limiting factor, since it should max out around 30-40 MB/s.
2 Likes
I’m sorry that I asked. 
The read speed shouldn’t be slower than the write speed!
The RS9116 WiFi/BT on the L5 also has slow speeds. I wonder what is the bottleneck.
1 Like
@amosbatto, here is another proposal (please check it), slightly changed, for microSD I/O performance testing on Librem 5. Only important thing before executing commands is that those need to be inside related (present) directory/partition (and for some kind of consistency my SDcard was formatted to ext4), therefore as first:
cd /media/USER/microSD_path
Today I’ve used count=2048 (perhaps 4096 would be ideal), yet quicker count of 512 will do as well. Note that for test_data files you’ll need su rights to remove those (sudo rm test_XX_data).
Just for coarse comparison results with the same HP mx310 UHS-I U1 100MB/s 64GB microSDXC card (only W and R commands changed to test_PP_data) inside PinePhone were:
Write: 215.399 s, 10.0 MB/s
Read: 180.912 s, 11.9 MB/s
cd / … to test_PP_eMMC_data:
Write: 129.938 s, 16.5 MB/s
Read: 27.9539 s, 76.8 MB/s
2 Likes
That worried me too. The only thing that I can think of is that hdparm -t is a rather short test (about 3 seconds?) for read, compared with dd for the write, which under the specific test conditions was about 20 seconds. Maybe 3 seconds is too short to give an accurate result in this case. I couldn’t see any way of asking hdparm -t to read more data.
It doesn’t get much better using dd ... if=test of=/dev/null
Using a 200MiB file, I’m getting 11 or 12 MB/s for read.
As a matter of interest, you can replace bs=1048576 with bs=1M for less typing.
The conclusion seems to be that the read speed is severely hampered by something in the Librem 5, when the card itself is seen to be capable of close to the advertised speed (100 MB/s for my uSD card).
2 Likes
If we’re talking about the SD card, then results of tests that take such a short time will likely be skewed by the latency of resuming the reader from power saving mode.
6 Likes
are we talking about a LUKS encrypted microSD card here or is it left unencrypted ?
from my experience on the LMini-v1 on the desktop side if you transfer files between encrypted medium source and encrypted medium destination the speed penalty can be quite severe (like 30 MB/s where the SSD drive normally does upwards of 200 MB/s easily in most cases)
Well, whatever is the bottleneck on the Librem 5, the PinePhone is similarly limited in its microSD speeds.
I expected much better performance from the PinePhone’s eMMC. The read speed of eMMC 5 in other phones can be as high as 400 MB/s. I would be very grateful if someone would do speed tests on the Librem 5’s eMMC as well.
2 Likes
Definitely unencrypted in my case.
Already (partly) done. Follow my links.
Unfortunately not blindingly fast either.
I’m only seeing a speed test of the L5’s microSD. Did you do a test of the L5’s eMMC (the internal Flash memory) as well?
Yes. The last post was a reply to the earlier post, which contained the test of the eMMC drive.
Anyway I redid the test of the eMMC drive. So the new last post has the results: [MyL5] Australia/New Zealand
So the PP is faster on the read and slower on the write than the Librem 5 - but not a dramatic difference in either case. Neither of them is blindingly fast. Also, I don’t know whether the eMMC drive is directly comparable between the two phones.
1 Like
Thanks @irvinewade and @Quarnero for doing the testing. I added your results to the wiki: https://source.puri.sm/Librem5/community-wiki/-/wikis/Benchmarks
2 Likes
Both the Librem 5 and PinePhone use eMMC 5.1 drives, but the A64 and i.MX 8M Quad only support up to eMMC 5.0, so that may limit the drives to some degree. However, the data sheet for the PinePhone’s eMMC drive says that the 16GB version should get sequential reads of 130MB/s and sequential writes of 45MB/s (I assume @Quarnero has the 16GB version). Kioxia doesn’t publicly release the data sheet for the Librem 5’s eMMC drive, but the best eMMC 5.0 drives have sequential reads of 250 MB/s and sequential writes of 90 MB/s.
I wonder what is causing the Librem 5 and PinePhone to have such slow storage.
The 32GB Kioxia (formerly Toshiba) THGBMHG8C2LBAIR in the Librem 5 and the 16GB Kimtigo KM111SS0016GxA-DDD00WT in the PinePhone should be able to support higher speeds. I can’t find the data sheet for the THGBMHG8C2LBAIR, but the data sheet for its larger 64GB variant, the THGBMHG9C4LBAIR, lists higher speeds for the chip.
Sequential read and write performance of eMMC drives in MB/s, according to their data sheets
| eMMC NAND Flash drive | DDR read | DDR write | HS200 read | HS200 write | HS400 read | HS400 write |
|---|---|---|---|---|---|---|
| 64GB Kioxia THGBMHG9C4LBAIR | 90 | 80 | 180 | 105 | 300 | 105 |
| 16GB Kimtigo KM111SS0016GxA-DDD00WT | 130 | 45 | 200 | 50 | ||
| 32GB Kimtigo KM110SS1032GxA-DDD00WT | 140 | 75 | 210 | 90 |
2 Likes
I’ve replaced (myself) the default 2GB/16GB mainboard (it was special offer, limited and now out of stock), meaning that above measurement was done with upgraded 3GB/32GB version. But please give me few days and I’ll test, benchmark R/W performance with the Pinephone 16GB eMMC variant (probably quicker) as well.
Actually, thanks for putting things together! I’m simply able to get much better overview (of so many technical things).
Thanks.
Minor correction: In the Wiki you say that read speeds were tested using hdparm. That was initially true. However that gave even more woeful speeds and @ dos pointed out that, because devices may be sleeping on the Librem 5, you need a longer test to make the time to wake-up less significant - and there doesn’t seem to be an argument to hdparm to control how much data is moved in the testing. So I did the tests again on the Librem 5 but using dd for the read test i.e. dd was used for both read and write.
However I didn’t retest the uSD on the x86 because I only have one card (of that spec) and that would mean shutting down the Librem 5, opening up, …
That does mean my presentation of results is not as clear as it could be, so confusion is inevitable.
1 Like
I updated the wiki to indicate that the benchmark is dd instead of hdparm.