SD cards speed and power consumption tests

[espruino-discuss2]

Posted at 2019-07-21 by AkosLukacs

I did some timing & power consumption measurements with a couple of SD cards.
My setup is not perfect, don't have a scope set up, so just did reads and writes in a loop for 10 seconds, and measured the power consumption.

Hardware:

• USB port :)
• Ruideng UM25C to measure the current consumption. 100uA resolution. Don't know about it's absolute accuracy, but the values are pretty consistent. Update speed could be a bit faster...
• Pixl.JS 2v04
• SD card adapter, wire length is about 10cm

SD Cards:

• really old TwinMos 128Mb card
• Sandisk Ultra 32Gb (got it like 5-6 years ago)
• Sandisk EDGE 16Gb (got it last year with a Raspberry Pi bundle)

Tests done:

• append a 46 character long line to an existing file (to simulate adding a new line to a log file. This is my original use case)
• read a 4 character file
• read a 334 character long file

A helper function (runs the funk function continuously for seconds seconds, and returns how many times it had executed):

function doFor(seconds, funk) {
     if (isNaN(seconds)) {throw new Error("seconds NaN!")}
     if (!(typeof funk === 'function')) {throw new Error("funk ! function!")}
     // warmup
     funk();
     var endT = (new Date()).getTime() + 1000 * seconds;
     var ts = 0;
     while ((new Date()).getTime() < endT) {funk(); ts++;}
     return ts;
}

Test values and files for perf measurements:

// two test files, one is 4 characters long, the other is 334 characters long Lorem Ipsum :)
fs.writeFile("4ch.txt", "alma")
fs.writeFile("334ch.txt", `In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document without relying on meaningful content (also called greeking).Replacing the actual content with placeholder text allows designers to design the form of the content before the content itself has been produced.`)

// just a row of data
sor = "Thu Jan 1 1970 00:06:43 GMT+0000,100,22.5,233\n"

// reading the files:
doFor(10, function(){fs.readFile("4ch.txt")})
doFor(10, function(){fs.readFile("334ch.txt")})

// writing data:
doFor(10, function(){fs.appendFile("teszt.txt", sor)})

Baseline power consumption:

• Pixl idle, no BLE connection, LCD on: 100uA
• Pixl idle, BLE connected: 0.9-1mA
• Pixl idle, BLE disconnected after writing 128Mb (SD mounted, LCD off): 2-300uA
• Pixl idle, BLE disconnected after writing 32Gb Sandisk (same if SD still mounted or unmounted): 5-600uA
• Pixl idle, BLE disconnected after writing 32Gb Sandisk (SD unmounted, LCD off): 3-400uA
• Pixl connected & running in a loop doFor(10, function(){}): 8.4mA

Some surprises:

• all cards work just fine at 8MHz SPI clock with this setup. (altho' I didn't check every single byte, data seems to be OK on all cards...)
• reading 4 bytes of data takes almost as much time as reading 334 bytes. Ok, probably isn't surprising if someone knows that data is stored in sectors...
• the old 128Mb card beats the 16Gb Sandisk in both speed and power consumption. Beats the newer card even more, if we adjust the power consumption for read/write speed.

The 32Gb Sandisk Ultra is faster, and consumes more power.
But if we assume that a single read or write takes the propotionally less time, it's overall energy consumption is lower, if we go to 1MHz reads and 2MHz writes and above. Write energy consumption:

• 18mA, 14.8 write/sec with the old card -> 1.22 mili-amper-second for one write
• 31.2mA, 27.4 write/sec with the 32Gb card -> 1.14 mili-amper-second for one write

So looks like the fastest card at the highest speed is the winner?
But 30mA current is a bit high if you run on a coin cell. Or might not matter, because a capacitor could smooth out a single write-spike? Dunno, I guess that's the point where a proper setup with an oscilloscope would be handy.

Raw data in the attachment

Attachments:

• sdperf.ods

[espruino-discuss2]

Posted at 2019-07-21 by Robin

Sun 2019.07.21

Hey good morning @AkosLukacs. Quite an impressive all inclusive undertaking!

This topic is a bit out of my league. I'm basing my comment on what I have read. Wasn't able to quickly locate the links I Had, still searching.

I took a quick peek at the data and the results, then looked at a datasheet or two. Although I currently am unable to locate a thorough complete document, it appears the values above are less than those on the manufacturer datasheet.

Someone please correct this should the following be in error, but aren't these devices reading and writing in blocks, or when spanning more than one block, and could that skew the data write? What about an erase or clear? Doesn't a page of blocks have to be cleared before an actual write takes place? I also remember that a write only occurs if the data bit at the write location changed, so r/w the same data doesn't change a thing and the current therefore would be much less. I don't recall if writing clears the bit or vise-versa. One requires current the other doesn't. Didn't @allObjects post on this topic a while back?

> 'that's the point where a proper setup with an oscilloscope would be handy'

It's likely that most reading this have the same desire. Car vs oscilloscope. Add to your X-Mas wish list. Mines been there for thirty years!! ;-)




EDIT: Good Evening! (from post #2, refraining from over posting to this thread)

'Morning? /me cooking dinner :)'

Keep forgetting that most forum users seem to be around GMT time zone, and it is just allObjects and myself that are a quarter of the world away and behind GMT . . .

Hey, that would make for a really great app!

[espruino-discuss2]

Posted at 2019-07-21 by AkosLukacs

Morning? /me cooking dinner :)

Oh, looks like there is a misunderstanding in the write part, added this to the original post:

Tests done:

• append a 46 character long line to an existing file (to simulate adding a new line to a log file. This is my original use case)
• read a 4 character file
• read a 334 character long file

So on the write tests the file is continuously growing.
Did the read tests out of curiosity / for completeness's sake. Right now I don't intend to read the data with Espruino.

The power consumption is more than likely to be lower than manufacturer's values, because there is the overhead of JS execution (reading and writing small chunks of data each time), and also it's a Pixl.JS, and that has to maintain Bluetooth connection. So I'm pretty sure not even close to real 100% duty cycle.
Now thinking about that: probably I'm wrong about the maximum current draw, and the real max current is higher.

(kind-of sort-of have a scope, but haven't really used it. They forked Sigrok / Pulseview, and the software support was pretty meh for a long time. I think the logic analyzer part is supported by Sigrok, but the scope part is still not supported in Sigrok. In hindsight, probably should have skipped it...)

[gfwilliams]

Posted at 2019-07-22 by @gfwilliams

Thanks for posting that up - it's really handy to know about the consumption with the SD card, as I'd really expected that might be higher.

Where did the 30mA figure come from? In your use case (writing a small log message) I'd imagine capacitors would smooth at least the 10mA enough that it's not hurting the coin cell too much.

If you're interested, you'll find that writing to a file opened with E.openFile is way faster - fs.writeFile is having to open the file first, which requires a few sector reads I believe... However for logging you'll probably want to have the file closed in case there's a power failure and it corrupts the file.

[espruino-discuss2]

Posted at 2019-07-22 by AkosLukacs

Some background info: basically, I want to log a row of data (about 100-200 bytes) every minute. Saw the E.openFile method, but since I don't write continuously, just using append felt safer & simpler.
Would be powered by a power bank, because I need 5 volts for the PMS7003, but wanted to test the coin cell backup.
First I modified the Pixl as described in "CR2032 battery backup" section and did some testing with the coin cell writing a row every 3 seconds. Was working fine for a couple of hours, but eventually the SD card didn't like the low voltage :)
Then wanted to do some power measurements, but that took a "bit" longer than expected... Without a scope, just run reads or writes continuously for 10 seconds, and wrote the current value. That 30mA is the "average" consumption of the Pixl.Js + SD card.

But probably would need a scope or some more sophisticated method to really capture what's going on.