Ideas for Real World HDD & SSD benchmarks ?

[wolf2009]

What REAL-WORLD benchmarks can one do, that can be easily be done by everybody else.

I was thinking copy some files from a drive to the same drive using this program
http://nodesoft.com/DiskBench/Default.aspx

Another benchmark could be muxing two 4 GB AVI files in Virtualdub.

What do you guys think ?

 

[taltamir]

mkvtoolnix remuxing / demuxing. but i expect it to be similar to virtual dub's process.

 

[wolf2009]

Originally posted by: taltamir
mkvtoolnix remuxing / demuxing. but i expect it to be similar to virtual dub's process.

problem with that would be to find two large mkv files. i can get avi files easily from fraps recording.

 

[wolf2009]

bump

 

[Nothinman]

What REAL-WORLD benchmarks can one do, that can be easily be done by everybody else.

The term "real-world benchmark" is an oxymoron, there's no such thing.

problem with that would be to find two large mkv files. i can get avi files easily from fraps recording.

Both AVI and MKV are just container formats, the data is stored in whatever codec is defined for that individual file.

 

[Rubycon]

Originally posted by: Nothinman

The term "real-world benchmark" is an oxymoron, there's no such thing.

This is so true.

I've spent countless hours fine tuning to get benchmarks to produce better numbers. At the end of the day when I sit down and do actual work nothing is really different. But it can be fun.

 

[taltamir]

Originally posted by: wolf2009

Originally posted by: taltamir
mkvtoolnix remuxing / demuxing. but i expect it to be similar to virtual dub's process.

problem with that would be to find two large mkv files. i can get avi files easily from fraps recording.

why two?
you don't have to splice them together... get one file and remux it to another file (it reads the streams from existing file and writes them into a new file in mkv container)

 

[taltamir]

Originally posted by: Nothinman

What REAL-WORLD benchmarks can one do, that can be easily be done by everybody else.

The term "real-world benchmark" is an oxymoron, there's no such thing.

problem with that would be to find two large mkv files. i can get avi files easily from fraps recording.

Both AVI and MKV are just container formats, the data is stored in whatever codec is defined for that individual file.

yes... AVI is older so it is more limited in its contents... but typically they have an MP3 audio stream and a MPEG4 video stream. which can easily be remuxed back and forth between pretty much any container LOSSLESSLY without reencoding. (It is also as fast as your HARD DRIVE to remux something, it does not really involve the CPU at all)

 

[taltamir]

oh i have another one... take magicISO, and use its "convert image" function to convert a bin image to an ISO.
no wait, ISO has compression (slight)... convert ISO to bin!

 

[Nothinman]

yes... AVI is older so it is more limited in its contents... but typically they have an MP3 audio stream and a MPEG4 video stream. which can easily be remuxed back and forth between pretty much any container LOSSLESSLY without reencoding. (It is also as fast as your HARD DRIVE to remux something, it does not really involve the CPU at all)

What limitations?

And typically means nothing, you could say that a zip file typically contains a txt file as well and it would be equally as meaningless.

 

[taltamir]

ZIP is for any compressed data, AVI is Audio Video Interlace. It is specifically audio and video. Saying it is typically MP3 audio is like saying that cars typically run on gasoline, a few run on electricity or oil or diesel, but typically a car uses gasoline
The limitations are:
1. Very limited amount of supported codecs
2. Relatively large overhead
3. only ONE audio and ONE video stream allowed, and only a few subtitle streams. with MKV for example, you can have a video stream, 5 different language streams, and 25 subtitle streams (you can actually have much more, but I am saying what I have actually seen... this is impossible in AVI or ogm). (you only need to the video twice, so you save space)

 

[Nothinman]

1. Very limited amount of supported codecs

It supports any codec that has a FourCC tag.

2. Relatively large overhead

The overhead for each container format varies depending on what's actually in the file, but really who cares? With the power of today's computers, size of hard disks, etc even if it was bad enough to waste like 15% space no one would notice.

only ONE audio and ONE video stream allowed, and only a few subtitle streams.

According to this http://www.alexander-noe.com/video/amg/en_myths.html you can have up to 256 streams of either audio or video.

 

[taltamir]

1. according to the wbesite you linked it needs a hack to run xvid/divx. and the whole purpose of ogm is to overcome its inability to play OGG audio. I am not certain about its ability with x264
2. A 200MB MKV will be a 208MB AVI or so... OGM has about the same if not worse overhead as AVI. Not a HUGE deal though.
3. I guess I was wrong about that, or at least about this being an AVI limitation rather than a limit on programs that decode AVI.

 

[ShawnD1]

Originally posted by: Nothinman

What REAL-WORLD benchmarks can one do, that can be easily be done by everybody else.

The term "real-world benchmark" is an oxymoron, there's no such thing.

I think Anandtech's benchmarks are real world. They test map load times for games, they test how fast an application opens when doing random stuff in the background like virus scanning, they measure raw speed with sandra, they test latency.

oh i have another one... take magicISO, and use its "convert image" function to convert a bin image to an ISO.
no wait, ISO has compression (slight)... convert ISO to bin!

I don't know about this one. That sounds like a CPU-limited task.

 

[Nothinman]

I think Anandtech's benchmarks are real world. They test map load times for games, they test how fast an application opens when doing random stuff in the background like virus scanning, they measure raw speed with sandra, they test latency.

Except that all of that is affected by what the OS and other apps running in the background are doing at that moment. If I start up a game and while that's happening my mail program decides to check for and download some emails and then I get an IM that load time will be longer than if none of that happened. And then if I quit the game and start it up again immediately the last map loaded should be cached in memory so it'll get there in a fraction of the time compared to the last time.

With benchmarks you can determine what the best possible scenarios are, but that's about it. There are too many variables to determine anything other than that.

I don't know about this one. That sounds like a CPU-limited task.

The ISO format has no compression in it although it looks like the RockRidge extensions do support it as a non-standard extension and it looks like it's only supported by Linux.