Compact Flash, USB Thumb drive, or hard drive?
Compact Flash, USB Thumb drive, or hard drive?
I've been testing a 35MB/s read and 20MB/s write usb thumb drive which works rather well. Pricing in order from low to high is:
usb thumb drive
compact flash
hard drive (expensive because it's impossible to find a small one)
I'm interested in a pro/con opinions.
usb thumb drive
compact flash
hard drive (expensive because it's impossible to find a small one)
I'm interested in a pro/con opinions.
I would be concerned about long term reliability of flash devices. They are rated for a finite number of write operations. Depending on how your software works (i.e. load once work from memory vs a constant read/write to the drive) that could be a real issue.
Of course, that issue could be mostly moot, if the user were given a way to easily produce a subsequent flash drive to replace a dead one. The prices on thumb drives do make that viable.
Of course, that issue could be mostly moot, if the user were given a way to easily produce a subsequent flash drive to replace a dead one. The prices on thumb drives do make that viable.
I dont think a cfcard has any upsides compared to a usb thumbdrive.
The upsides with a thumbdrive compared to a hd would be less heat production, better tolerance to shocks, smaller and lower accesstimes (?). The downsides would be as previously stated probably less writecycles and limited space.
How much storagespace does the "product" require?
The upsides with a thumbdrive compared to a hd would be less heat production, better tolerance to shocks, smaller and lower accesstimes (?). The downsides would be as previously stated probably less writecycles and limited space.
How much storagespace does the "product" require?
Thumb drives are cheap and reliable. As long as they can easily be replicated by end users I'd go that route. With "limited" write cycles of 100k writes I don't see that as being a big issue, especially since a decent thumb drive will wear level the blocks. More of an issue would be future compatibility, since the technology keeps changing (p3, etc). Actually, if you stick with USB any mass storage class device would probably work, so if a customer wanted a USB hard drive they could probably go that route.
Maybe we should make it a 'request'. Design the system to not wear out Flash Drives. It strikes me that most of the time running the game is a 'read' operation and the data is stored in memory. However, logging could be a concern... some programs can produce a LOT of logging.ChadTower wrote:Kenbo wrote:With "limited" write cycles of 100k writes I don't see that as being a big issue
Depending on the IO details of their implementation it could be a major issue. If they are going heavy on disk IO a thumb drive may not last long at all.
The most important thing, I think, would be making it easy to backup and restore the data from whatever device it is. This is the main problem with the exisiting ROM situation. Difficult or impossible to replace game and program data in the event of failure.
Have they made that info public yet? We have no idea what emulating the original platform may have forced them to do - they haven't reimplemented it, AFAIK, they have emulated it. A number of seemingly odd IO paths are possible depending on how the original was done. Emulation doesn't usually follow the common sense IO design paths.Andrew wrote: Maybe we should make it a 'request'. Design the system to not wear out Flash Drives. It strikes me that most of the time running the game is a 'read' operation and the data is stored in memory. However, logging could be a concern... some programs can produce a LOT of logging.
Fully agreed. Doesn't make any sense to design a potentially expensive replacement solution around a $10 flash drive if it were a potential failure point.The most important thing, I think, would be making it easy to backup and restore the data from whatever device it is. This is the main problem with the exisiting ROM situation. Difficult or impossible to replace game and program data in the event of failure.
It would be interesting to know the algorithm used by the p2k software. If it writes to storage each time a logged event occurs then writes could be heavy but if it accumulates stats and writes them at the end of each game or at some other predetermined interval then a decent flash wear leveling algorithm should minimize wear. Does the original implementation use battery backed SRAM or flash or eeprom or ??? Sorry, I haven't looked into details. But a USB solution should still support any mass storage class so if wear is an issue use a USB hard drive.ChadTower wrote:Kenbo wrote:With "limited" write cycles of 100k writes I don't see that as being a big issue
Depending on the IO details of their implementation it could be a major issue. If they are going heavy on disk IO a thumb drive may not last long at all.
The original uses flash ram. We can count how many times the machine will write data during normal use and will take that into consideration.Kenbo wrote:It would be interesting to know the algorithm used by the p2k software. If it writes to storage each time a logged event occurs then writes could be heavy but if it accumulates stats and writes them at the end of each game or at some other predetermined interval then a decent flash wear leveling algorithm should minimize wear. Does the original implementation use battery backed SRAM or flash or eeprom or ??? Sorry, I haven't looked into details. But a USB solution should still support any mass storage class so if wear is an issue use a USB hard drive.ChadTower wrote:Kenbo wrote:With "limited" write cycles of 100k writes I don't see that as being a big issue
Depending on the IO details of their implementation it could be a major issue. If they are going heavy on disk IO a thumb drive may not last long at all.
The original also uses battery backed sram / nvram for most of it's settings. The flash ram is written to in case of losing the nvram data, but I have no idea if the code copies all of the nvram, or just some of it. Extensive logging of the emu would be required to find out, but it's a low priority.Chuck wrote:The original uses flash ram. We can count how many times the machine will write data during normal use and will take that into consideration.Kenbo wrote:It would be interesting to know the algorithm used by the p2k software. If it writes to storage each time a logged event occurs then writes could be heavy but if it accumulates stats and writes them at the end of each game or at some other predetermined interval then a decent flash wear leveling algorithm should minimize wear. Does the original implementation use battery backed SRAM or flash or eeprom or ??? Sorry, I haven't looked into details. But a USB solution should still support any mass storage class so if wear is an issue use a USB hard drive.ChadTower wrote:
Depending on the IO details of their implementation it could be a major issue. If they are going heavy on disk IO a thumb drive may not last long at all.
Needless to say, as many of you guessed, most of the time, the usb key or whatever device we use will be doing read operations, with seldom writes. I doubt anyone would burn out their keys for many many years if ever.
That's exactly what we're doing, it loads everything into memory and runs from there, so the key is only read when you turn the game on initially.JMX wrote:Wouldn't it be possible to have linux load itself + the emulator from the usb to the ram, and run everything from there. And just write the important stuff to the usb once in a while?
As for the writes, we're still working on a few things to see what the best way to handle it is, but we will certainly keep the writes to the key as minimal as we can get w.o jeopardizing losing settings/scores/audits etc..