Compact Flash, USB Thumb drive, or hard drive?

Talk about anything PB2K related.
User avatar
Chuck
Site Admin
Posts: 1546
Joined: Wed Mar 28, 2007 3:34 pm
Location: Michigan
Contact:

Compact Flash, USB Thumb drive, or hard drive?

Post by Chuck »

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.
ChadTower
Veteran
Posts: 103
Joined: Wed Feb 13, 2008 10:16 am

Post by ChadTower »

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.
JMX
member
Posts: 18
Joined: Sun Feb 17, 2008 8:56 am
Location: Sweden

Post by JMX »

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?
ChadTower
Veteran
Posts: 103
Joined: Wed Feb 13, 2008 10:16 am

Post by ChadTower »

USB thumbdrives are up to 16G now. Could P2K possibly be using that much?
User avatar
Chuck
Site Admin
Posts: 1546
Joined: Wed Mar 28, 2007 3:34 pm
Location: Michigan
Contact:

Post by Chuck »

ChadTower wrote:USB thumbdrives are up to 16G now. Could P2K possibly be using that much?
No, not even near it. We are working on making the complete build as small as possible. Smaller =quicker loading and lower price on storage device. I'm using a 4gb thumb drive now and have plenty of free space ;-)
Kenbo
Veteran
Posts: 102
Joined: Tue Feb 12, 2008 6:16 pm
Location: NW Oregon

Post by Kenbo »

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.
ChadTower
Veteran
Posts: 103
Joined: Wed Feb 13, 2008 10:16 am

Post by ChadTower »

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.
Andrew
member
Posts: 14
Joined: Tue Feb 26, 2008 1:40 pm
Location: Fort Wayne, IN

Post by Andrew »

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.
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.

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.
ChadTower
Veteran
Posts: 103
Joined: Wed Feb 13, 2008 10:16 am

Post by ChadTower »

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.
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.


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.
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.
User avatar
Chuck
Site Admin
Posts: 1546
Joined: Wed Mar 28, 2007 3:34 pm
Location: Michigan
Contact:

Post by Chuck »

It has always been my plan to make the software part of the solution available to customers via the web. No matter which drive type is chosen you could, and eventually would, have failure. We will provide a way for you to recover from that.
Kenbo
Veteran
Posts: 102
Joined: Tue Feb 12, 2008 6:16 pm
Location: NW Oregon

Post by Kenbo »

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.
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.
User avatar
Chuck
Site Admin
Posts: 1546
Joined: Wed Mar 28, 2007 3:34 pm
Location: Michigan
Contact:

Post by Chuck »

Kenbo wrote:
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.
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.
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.
User avatar
sellenoff
Project Developer
Posts: 79
Joined: Wed May 02, 2007 1:05 pm

Post by sellenoff »

Chuck wrote:
Kenbo wrote:
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.
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.
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.
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.

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.
JMX
member
Posts: 18
Joined: Sun Feb 17, 2008 8:56 am
Location: Sweden

Post by JMX »

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?
User avatar
sellenoff
Project Developer
Posts: 79
Joined: Wed May 02, 2007 1:05 pm

Post by sellenoff »

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?
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.

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..
Post Reply