SD card write performance

[bigmessowires]

Hi, I've been working on a project similar to HxC: a floppy emulator for classic Mac computers. You can see the development log here: http://www.bigmessowires.com/category/m ... loppy-emu/

I've discovered that single block write performance for the SD card is highly variable, and often slow enough that it breaks the floppy emulation. With a class 4 HDSC card (4 MB/sec), I typically see single block write times between 3 and 7 milliseconds, but sometimes it shoots up to 50-80 milliseconds and stays there for many consecutive block writes. This is too slow, so the Mac write operation times out.

Does the HxC floppy emulator require a specific type or brand of SD card in order to support writes? Does the firmware do anything special to mask the write latency? Do you know the approximate SD card write times for a single block with the HxC emulator?

Thanks for your help!
Steve

[Jeff]

Hi, I've been working on a project similar to HxC: a floppy emulator for classic Mac computers. You can see the development log here: http://www.bigmessowires.com/category/m ... loppy-emu/

I've discovered that single block write performance for the SD card is highly variable, and often slow enough that it breaks the floppy emulation. With a class 4 HDSC card (4 MB/sec), I typically see single block write times between 3 and 7 milliseconds, but sometimes it shoots up to 50-80 milliseconds and stays there for many consecutive block writes. This is too slow, so the Mac write operation times out.

Does the HxC floppy emulator require a specific type or brand of SD card in order to support writes? Does the firmware do anything special to mask the write latency? Do you know the approximate SD card write times for a single block with the HxC emulator?

Thanks for your help!
Steve

Yes this was one major issue/problem to solve during the floppy emulator development.
Note: 80ms is a good timing... i have already see 200ms .

2 advices :
-> You should use the multisector write method. the write throughput is a lot better.
-> In some case you probably also need to add a small ram (~16KB / 32KB) to store the incoming write stream...

This is why there are a 32KB sram chip on the HxC

[bigmessowires]

Ah, thanks, I didn't realize there was an external 32K SRAM. That makes sense.

200 ms... wow!

What happens if you begin a long multi-sector write operation of the data from SRAM, and in the middle of it the computer requests a read of some other sector? You can't read the new sector, because the SD card is already in use for the multi-sector write.

As I think about it now, that seems like it would be a problem regardless of how much buffering space you have, or whether you use multi-sector or single-sector writes. If any block write to the SD takes an unexpectedly long time, like your 200 ms example, then the SD card is unavailable for other uses during that time. If the computer decides to step to a new track and begin reading during that time, the emulator won't be able to provide the data.

[Jeff]

Ah, thanks, I didn't realize there was an external 32K SRAM. That makes sense.

200 ms... wow!

What happens if you begin a long multi-sector write operation of the data from SRAM, and in the middle of it the computer requests a read of some other sector? You can't read the new sector, because the SD card is already in use for the multi-sector write.

As I think about it now, that seems like it would be a problem regardless of how much buffering space you have, or whether you use multi-sector or single-sector writes. If any block write to the SD takes an unexpectedly long time, like your 200 ms example, then the SD card is unavailable for other uses during that time. If the computer decides to step to a new track and begin reading during that time, the emulator won't be able to provide the data.

In fact in your case i think that a track buffer should be enough :
-> Load all sectors of a track in a sram
-> proceded all the read/write operations from/to this buffer.
-> On track change, read all sectors of the new track in another "track room". if a write occured on the previous track, write back the sector(s) to the sdcard.

Since the MAC disk drive is able to change the disk drive rotation, i think that you have more time for the write back at this moment. Also you can probably make the MAC to wait more during the stepping with the STEP disk drive register ?

Another very important question/possible issue :
Are you sure that this a time-out issue ? This can also be a PLL problem.
What do you stream out when you write back to the SDCard ? If nothing, the FDC PLL/VFO may lost the sync, and the next sector could not be read correctly. Have you tried to stream out a GAP value during the write back ? This may be interesting. Do you send enough GAP bytes before the sector bytes ?

A last point : be carefull with the read line state during the write. i got a similar issue in the past (i mean something that looked like a time-out issue on slow sdcard). But in fact this was because the read line was sometime forced to 0 during the write due to a bug -> PLL desync .

[bigmessowires]

The slow SD card write times happen even with a simple test program that doesn't communicate with the Mac. So I'm pretty certain it's the card, and not something with my emulator firmware. I tried using a high-speed class 10 SDHC card, and the write times are more consistent (about 6 ms), but are actually slightly longer than with the other card.

My emulator is not able to send sectors from RAM to the Mac (for a read) at the same time as writing dirty sectors back to the SD card-- it can only do one thing at a time. There is a CPLD connected to the microcontroller. When the mcu is writing back to the SD card, the CPLD provides sync bytes to the Mac, which is what I think you meant. So the Mac will stay in sync, but if the SD write takes too long, eventually the Mac will abort its read and return an error saying that it can't find the sector address mark. It will wait up to 23 ms for an address mark, so any write that takes more than 23 ms can cause a read failure.

When stepping between tracks, the Mac will wait up to 12 ms for the STEP register to change. If a step takes longer than 12 ms, it will abort and return a "can't step" error.

Using the class 10 card, my emulator is fast enough for what I call normal writes, which are your typical file operations. The normal writes are actually alternating patterns of read-write-read-write, where the computer reads to find the start of the sector it wants to update, then overwrites the sector data, then reads to find the start of the next sector, and so on.

My emulator is not currently fast enough for what I call continuous writes, which occur when initializing a floppy, or when writing to a floppy using a disk copy program. With continuous writes, the Mac writes an entire track in one pass without stopping. Since the rate of sectors written per second is higher than with normal writes, the SD card is too slow to keep up.

The emulator uses very little RAM for buffering: there are just two 512 byte buffers. Most reading and writing to the SD card is done on the fly, as needed. By choosing a different AVR, I could get up to 16KB of internal RAM, which would be enough for both sides of a single track, with a little bit extra. I'd prefer not to use any external RAM.

-> Load all sectors of a track in a sram
-> proceded all the read/write operations from/to this buffer.
-> On track change, read all sectors of the new track in another "track room". if a write occured on the previous track, write back the sector(s) to the sdcard.

If you mean to do those steps sequentially, then I think there's not enough time. It would need to read all 24 sectors for both sides of the new track, and write up to 24 dirty sectors from the old track. Even if the SD card were super fast, it would still take about 1 ms per sector just to send/receive the data over SPI with a 4MHz SPI clock. That would be a total of 48 ms, when a track step is only allowed to take 12 ms.

If you mean to do those steps in parallel, then it might work, but the design would be more complex. Something like:
- on track change, begin to read all the sectors of the new track into another track room
- as soon as the first sector is received from the SD card, begin to send it to the Mac, at the same time as the remaining sectors are read from SD
- if the computer does a write, store the data in the new track room. In the case of a continuous write, this may actually write a sector that hasn't been read from SD card yet
- once all sectors have been read from the SD card, send them in a continuous loop to the Mac, at the same time as writing the dirty sectors from the old track.

This would require having enough memory to buffer both sides of two entire tracks, which is 24K for the Mac. And this still might fail, since there's no guarantee that the dirty sectors from the old track will be written back to the SD card before the Mac changes tracks yet again. But in practice it probably doesn't move through tracks that quickly.

Thank you for giving help with my emulator design, it's very kind of you and I greatly appreciate it!

[Jeff]

My emulator is not currently fast enough for what I call continuous writes, which occur when initializing a floppy, or when writing to a floppy using a disk copy program. With continuous writes, the Mac writes an entire track in one pass without stopping. Since the rate of sectors written per second is higher than with normal writes, the SD card is too slow to keep up.

Yes i confirm ! for continuous writes you need an additionnal buffer to store the track... no choice.

-> Load all sectors of a track in a sram
-> proceded all the read/write operations from/to this buffer.
-> On track change, read all sectors of the new track in another "track room". if a write occured on the previous track, write back the sector(s) to the sdcard.

If you mean to do those steps sequentially, then I think there's not enough time. It would need to read all 24 sectors for both sides of the new track, and write up to 24 dirty sectors from the old track. Even if the SD card were super fast, it would still take about 1 ms per sector just to send/receive the data over SPI with a 4MHz SPI clock. That would be a total of 48 ms, when a track step is only allowed to take 12 ms.

No, not really sequentially -> in the HxC the streaming and reading process are working in // . I think that you can read a first sector to begin to stream. No need to wait the end of the read track: Reading is faster than streaming
Sure the implementation is more complex, but nobody says that this is easy (especially if you want to make a low-cost device)

In conclusion : For the floppy emulation it is more interesting to have an MCU with a little more RAM than MHZ

[bigmessowires]

In conclusion : For the floppy emulation it is more interesting to have an MCU with a little more RAM than MHZ

Very true!

So does HxC work with any speed of SD card, even very slow ones?

I did some more tests with a class 4 SD card, doing sequential multi-block writes of an entire track at a time (24 512-byte sectors), and it consistently took about 370-380 ms. But for continuous writes during initialization of a floppy, the Mac only spends about 350 ms writing each track (two complete rotations of the disk at about 360 RPM). So with this SD card, even with full-track RAM buffering and sequential multi-block SD writes, it's still not fast enough.

Have you seen a similar issue with HxC, or are you using some other technique to handle slow SD cards?

[Jeff]

In conclusion : For the floppy emulation it is more interesting to have an MCU with a little more RAM than MHZ

Very true!

So does HxC work with any speed of SD card, even very slow ones?

I did some more tests with a class 4 SD card, doing sequential multi-block writes of an entire track at a time (24 512-byte sectors), and it consistently took about 370-380 ms. But for continuous writes during initialization of a floppy, the Mac only spends about 350 ms writing each track (two complete rotations of the disk at about 360 RPM). So with this SD card, even with full-track RAM buffering and sequential multi-block SD writes, it's still not fast enough.

Have you seen a similar issue with HxC, or are you using some other technique to handle slow SD cards?

With the 32KB SRAM i can store up to 3 tracks as track fifo for the write process and i use the multi sector write of the sdcard. (And i am at the max speed of the SPI bus : 10Mhz + all SD + Write routines are in ASM... )

But i think that there are an important difference between the MAC FDC and others FDC: Most shugart based FDC scan the track to find the sector to write. there no real timeout to find the sector: the only one is the index pulse. if the sector is not found after x index, an "sector not found" error can be generated. other timing : if the index don't appear after x ms (~1s on PC) -> Drive not ready.

A question : I suppose that the MAC FDC retry to read the track if it miss the sector header ? No?

[bigmessowires]

For typical sector-by-sector writes, yes, the Mac will scan the track to find the sector to write. There is a timeout of 23 ms to find the next sector, and if it reads more than 12 sectors without finding the correct one, a "sector not found" error is returned.

But when doing a full-track write during floppy initialization or a disk copy, the Mac writes the whole track without reading anything first. There is no index pulse for Mac floppies. So there's no way to slow down the write data coming from the Mac, at least not that I've found. During floppy initialization, it continuously writes at an average rate of about one complete track per 350 ms, which appears to be too fast for some cards, even when doing multi-block writes of pre-erased blocks.

I'm going to build a new prototype with 16K RAM for buffering, and a higher SPI clock, and see how it works. I think I can make it work for all type of writes with a class 10 card. For slower cards, it might not be able to support floppy initialization, but should still support normal write operations OK. I think that might be acceptable, since if you want to format an emulated floppy, you can always just copy a blank disk image from your PC to the SD card. But if I can make it fast enough to emulate floppy initialization, that would be better.

By the way, I saw in another thread that you're concerned about people cloning the HxC emulator. To be clear, I am working on building another floppy emulator, but not one that would compete directly with HxC since it will be Macintosh-only. But still, I'll understand if you don't want to reveal too much of the internal details of how HxC works. Thanks for answering my questions so far.