eMMC vs. SD-card benefits?

o_lampe

Hi gents,
in another thread I proposed to use an eMMC_to_SD-card dongle for RasPi/SBC.

Just wondering, if Duet-controllers could benefit from the higher read/write speed as well? ( their higher reliability would be welcome for sure!)

jens55

@o_lampe I run two PI4's, each with a 1T byte SSD drive via the USB3 port. One (possibly both) of them uses no SD-card and boot directly off the SSD. My main goal is reliability with speed being the other (assumed) advantage. I never did a speed comparison of SD card vs SSD drive.
I have had too many SD cards fail on me. I switched to high duty SD cards and had no more failures but I still don't trust them for critical service.

o_lampe

@jens55 The RPi definitely benefits from SSD, but here the question was related to Duet controllers and eMMC cards.
I'm bothered by the fact, that daemon.g runs only every 10 sec because of the SD-card handycap.
An eMMC card would be a big improvement here...

jens55

@o_lampe .... looks like my head was in PI space

dc42

@o_lampe said in eMMC vs. SD-card benefits?:

I'm bothered by the fact, that daemon.g runs only every 10 sec because of the SD-card handycap.

The reason for increasing the delay to 10 seconds was mainly to reduce the load on the CPU when there is no daemon.g file. The recommendation is to use a loop within the daemon.g file instead, with a G4 delay command in the loop to limit the CPU time it uses. This is more efficient because it avoids having to search for and open the daemon.g file each time.

o_lampe

@dc42 The way you describe daemon.g-behaviour makes total sense now, but in the past you always stressed how much the SD card wears out from excessive use of daemon.g. Until now my impression was, that using short loop times in the while-construct would still wear out the card. Good to know it doesn't

In M122 we can see the SD-card performance (eg. 20MB/s). Will that change with eMMC? I guess, I have to buy one, before they are sold out

dc42

@o_lampe said in eMMC vs. SD-card benefits?:

@dc42 The way you describe daemon.g-behaviour makes total sense now, but in the past you always stressed how much the SD card wears out from excessive use of daemon.g. Until now my impression was, that using short loop times in the while-construct would still wear out the card. Good to know it doesn't

In M122 we can see the SD-card performance (eg. 20MB/s). Will that change with eMMC? I guess, I have to buy one, before they are sold out

Wear occurs when you write to the SD card, not when you read from it. So it's only a concern in relation to daemon.g if daemon.g writes to the SD card frequently.

@o_lampe said in eMMC vs. SD-card benefits?:

In M122 we can see the SD-card performance (eg. 20MB/s). Will that change with eMMC? I guess, I have to buy one, before they are sold out

That is the interface speed. In practice, high speeds are only possible to/from SD cards when large block transfers are done (as happens in digital cameras, which is what SD cards are designed for). That's not possible on Duets because there is insufficient RAM buffer. In particular, if RRF writes a small block of data to the SD card, after the block ends the SD card is likely to be busy for a while.

o_lampe

@dc42 Will we see faster transfer rates while downloading huge gcode files? I was always impressed how fast RRF transfers files compared to Marlin.
There is a lot of (unused?) RAM on a WiFi module, can we borrow some of it for a "RAM-disk"? Not just as data buffer, but for several RRF features, which will otherwise not run on Duet2. (multi-gcode streams etc.)

JoergS5

@o_lampe an alternative could be flash connected by SPI, just out of curiosity I bought a W25N01GVZEIG with 128 MB. They are not expensive, about 3 EUR each. They could be used to extend the Duet memory for debugging purposes as well.

o_lampe

@joergs5 I had a similar idea, when I saw the RasPi Pico (RP2040) it has several SPI channels at 133MHz and could also act as Co-Processor or toolboard