ace101

Seek Times

Recommended Posts

When it comes to tools to assess just what a drive is doing, IPEAK SPT is among the best there is. Let's take a look at one of our disk traces... FarCry.

The SR DriveMarks and gaming tests are "random access time" measurements that take into effect real world conditions such as on OS's caching system, data localization, drive buffers and strategies, etc and deliver a response time (access time) result that is the average yielded by the given drive in the given application.

When you see the Deskstar 7K500 doing "763 IO/s per second" in FarCry, what you're seeing is that the Deskstar 7K500 turns in an average random access time of (1000/763) 1.31 milliseconds in FarCry.

All of the above is why high-level results such as the DriveMarks and game captures should vastly supecede "random access time" in the mind of all readers when evaluating potential drives for single-user use.

Whew. Who's still with me? :)

217603[/snapback]

Hmm--this could be misleading if it suggests the 7k500 will play Farcry faster ( frames per second) because it does more IO/s than another modern drive. I play FEAR on a 10kIV and a 7K250 (backup drive) in the same system. The Head to Head shows the SCSI with the better IO but fps are indeed equal. FPS are influenced by CPU , FSB and video card performance. If you tested game fps as part of the drive reviews you would soon not bother.

On the "feel good" matter, access times sure count more than you credit for single user average use performance , eg, web surfing, loading windows, mail , etc. I know I am beating the deceased mare here but I will take the 10k over ANY IDE for those purposes. I have recently installed the 10kV and now, honestly, I understand the phrase "a god in the machine."

Share this post


Link to post
Share on other sites

In your case, faster simply means "less likely to be a bottleneck". But when comparing hard drives to hard drives, such things matter. When comparing systems to systems, they will be less significant.

Anyway, once the level is loaded, HDD performance doesn't affect a game much. It's the loading screens that it will speed up, not the actual gameplay.

Share this post


Link to post
Share on other sites

well, it depends what you're doing, too. When I'm doing audio/video editing there is a great deal of additional performance from my striped drives. And while the gains for things like loading a game might not be as large, I've certainly noticed them none the less. I find it extremely annoying whenever I have to work on a machine that doesn't have striped drives, the difference is quite noticable, especially after having gotten used to the machine I use most having striped drives. If you only have sporadic experience using a machine with striped drives then the differences might not be too apparent, but once you get used to a machine with striped drives you can easily see the difference when you go to a machine that doesn't have them.

This is something I've long considered to be one of the dominate reasons behind the poor performance improvement offered by striping. It's great to have exact numbers to quantify it.

Share this post


Link to post
Share on other sites
""well, it depends what you're doing, too. When I'm doing audio/video editing there is a great deal of additional performance from my striped drives. And while the gains for things like loading a game might not be as large, I've certainly noticed them none the less.""

thanks for the clarifications. it does makes sense mostly in high end audio and video editing.

Share this post


Link to post
Share on other sites

hi ace101,

are you using any hdd that can do AAM, acoustic management? i think maxtor hdd or hitachi PATA can change from fast to quiet by relatively slowing access times a few ms on the same hdd.

This condition will be more realistic, same hdd, same data layout, same system. Only difference is the access times. its a more correlated way of saying whether game loading time is affected by access times. If different brands and models are being compared, additional variables will be unneccesary introduced as their strengths are different.

Its a crude and simple way.

Edited by AforceII

Share this post


Link to post
Share on other sites

hi ace101,

my above statements is focus only for one same hdd and loading of games access time, fast and quiet setting.

This cannot be used to compared hdds from different makes and models as loading of games does not depends on access time alone. There are many other factors.

Share this post


Link to post
Share on other sites

Those traces results from applications are really useful. It would be nice if SR could test some common applications activity (Photoshop, video/sound editing, Some games, 3D apps, Server/file server etc.) to reveal what really matters in those kind of apps, allowing users to shop for a drive that has peculiar characteristics (STR, access time, etc.)

Share this post


Link to post
Share on other sites
Very interesting, Eugene.

A drive may spend ~11% of its time servicing 16+ M sector requests, but uncached service requests encompass much more than just the 16+ M sector "long distance calls".

I would say that analyzing differences in seek performance from beyond 16 k sectors as opposed to 16 M is more representative when answering the question of how significant is seek performance to responsiveness.

Reframing this analysis to look at 16+ k sector requests, we find that a drive spends ~60% of its time servicing uncached requests. And that means the seek performance of a drive is more significant than you're giving it credit for.

Am I missing something here?

I strongly agree with e_dawg.

There are probably wrong assumptions made in Eugene's analysis:

"11% of requests stride more than 8 gigabytes... 80%, however, are within 8 megabytes. Given a decent read-ahead buffer algorithm, a large majority of those requests will be cached outright while the remainder will probably be on the same track (no seek) or at most a few tracks away (track-track seeking)."

For example, the Linux read-ahead algorithm only permits up to 128KB of read-ahead on a per-file basis, given the access pattern is sequential. If the access is detected non-sequential, read-ahead will be even minimized. So, at least in Linux, it's not the case that data as far as 8MB apart can be read ahead and thus cached at the same time. I'm not sure about the Windows algorithm, but Linux is definitely a decent OS.

More over, looking at the "Read Seek Profile" graphs of Hitachi Deskstar 7K400 and Fujitsu MAU3147, we see that the seek penalty quickly kicks in at distances of as short as 1K sectors (0.5MB) - which is very roughly the track size. The graphs actually also show that seeking to just a few tracks away is almost as bad as seeking to, say, 512K sectors (256MB) away.

So, looking at seek distances of 16M+ sectors only to calculate the potential benefit of better seek performance is flawed. We probably should take all seek distances of 1K+ sectors into consideration.

Share this post


Link to post
Share on other sites
For example, the Linux read-ahead algorithm only permits up to 128KB of read-ahead on a per-file basis, given the access pattern is sequential. If the access is detected non-sequential, read-ahead will be even minimized. So, at least in Linux, it's not the case that data as far as 8MB apart can be read ahead and thus cached at the same time. I'm not sure about the Windows algorithm, but Linux is definitely a decent OS.

I don't think you've adequately gone over the methodology ericyifeng. If a request in that chart is being served by the cache because the read-ahead algorithm caught it, it is the disk cache not the OS cache that acted. The disk cache acts independently of the OS. Your objections do not relate to the SR methodology. The OS cache is not involved in caching IPeak trace replays. So every cache hit Eugene notes is going to occur under this workload on any OS. IPeak isolates the disk subsystem, which is why it is such a valuable tool.

You need to make sure you understand a methodology before you declare it flawed.

More over, looking at the "Read Seek Profile" graphs of Hitachi Deskstar 7K400 and Fujitsu MAU3147, we see that the seek penalty quickly kicks in at distances of as short as 1K sectors (0.5MB) - which is very roughly the track size. The graphs actually also show that seeking to just a few tracks away is almost as bad as seeking to, say, 512K sectors (256MB) away.

So, looking at seek distances of 16M+ sectors only to calculate the potential benefit of better seek performance is flawed. We probably should take all seek distances of 1K+ sectors into consideration.

Did you take into account rotational latency? A hard disk drive isn't RAM. Just because there's latency doesn't mean there's a seek. According to the data, you did not. I'm sorry if this sounds harsh, but judging from the blatant flaws in your critques, you honestly need to sit back and learn a little more before you criticize the work of someone who has been doing this for years.

And before you redo your math to include rotational latency, and you tell me that I'm wrong. Make sure you do it with worse case latency, not average latency.

I hope this clarifies the nature of the issues that you raised. They are nothing more than spectres that research would have dismissed.

Share this post


Link to post
Share on other sites

For example, the Linux read-ahead algorithm only permits up to 128KB of read-ahead on a per-file basis, given the access pattern is sequential. If the access is detected non-sequential, read-ahead will be even minimized. So, at least in Linux, it's not the case that data as far as 8MB apart can be read ahead and thus cached at the same time. I'm not sure about the Windows algorithm, but Linux is definitely a decent OS.

I don't think you've adequately gone over the methodology ericyifeng. If a request in that chart is being served by the cache because the read-ahead algorithm caught it, it is the disk cache not the OS cache that acted. The disk cache acts independently of the OS. Your objections do not relate to the SR methodology. The OS cache is not involved in caching IPeak trace replays. So every cache hit Eugene notes is going to occur under this workload on any OS. IPeak isolates the disk subsystem, which is why it is such a valuable tool.

You need to make sure you understand a methodology before you declare it flawed.

I was not saying the methodology is flawed. I was just questioning the analysis which calculates the potential improvement on 8GB+ (or 16M+ sectors) seeks only and draws the conclusion that the improvement would be insignificant.

OK, let's talk about the hardware disk cache. Are you saying that seeks between, say, 1K and 16M sectors can be absorbed by the disk cache? I don't know the disk cache internals. However, it's hard for me to imagine that the disk cache would do such large read-aheads (1K - 16M sectors or 0.5MB - 8GB), especially when the disk is actually busy.

BTW: is the hardware disk cache on or off in the IPEAK SPT tests? If it's on, then why are we seeing considerable time spent on seeks between 512 and 16M sectors if they should be cached? If it's indeed off, well, that's good to know and can we also see the times with the cache on?

More over, looking at the "Read Seek Profile" graphs of Hitachi Deskstar 7K400 and Fujitsu MAU3147, we see that the seek penalty quickly kicks in at distances of as short as 1K sectors (0.5MB) - which is very roughly the track size. The graphs actually also show that seeking to just a few tracks away is almost as bad as seeking to, say, 512K sectors (256MB) away.

So, looking at seek distances of 16M+ sectors only to calculate the potential benefit of better seek performance is flawed. We probably should take all seek distances of 1K+ sectors into consideration.

Did you take into account rotational latency? A hard disk drive isn't RAM. Just because there's latency doesn't mean there's a seek. According to the data, you did not. I'm sorry if this sounds harsh, but judging from the blatant flaws in your critques, you honestly need to sit back and learn a little more before you criticize the work of someone who has been doing this for years.

And before you redo your math to include rotational latency, and you tell me that I'm wrong. Make sure you do it with worse case latency, not average latency.

I hope this clarifies the nature of the issues that you raised. They are nothing more than spectres that research would have dismissed.

The graphs clearly state "Read Seek Profile" so I naturally ignored rotational latency. So what are the graphs really meant to show? Seek latency? Rotational latency? Or both?

BTW: I'm an infrequent visitor to the SR website so I'm not familar with the test methodology used here. I stumbled upon this discussion from the main page link and I'm just saying what I feel might be wrong. After all I guess the forum is meant to stimulate discussion rather than follow what the authoritative say. I apologize if my words are offensive.

Share this post


Link to post
Share on other sites
The graphs clearly state "Read Seek Profile" so I naturally ignored rotational latency. So what are the graphs really meant to show? Seek latency? Rotational latency? Or both?

Eugene answered this in the first sentence under the graphs:

These are three-dimensional graphs... along the x-axis, you have stride, on the y-axis, response time (access time), and on the z-axis (color), the % of access times that fell into the particular stride/time combo.

Share this post


Link to post
Share on other sites

You need to make sure you understand a methodology before you declare it flawed.

I was not saying the methodology is flawed. I was just questioning the analysis which calculates the potential improvement on 8GB+ (or 16M+ sectors) seeks only and draws the conclusion that the improvement would be insignificant.

OK, let's talk about the hardware disk cache. Are you saying that seeks between, say, 1K and 16M sectors can be absorbed by the disk cache? I don't know the disk cache internals. However, it's hard for me to imagine that the disk cache would do such large read-aheads (1K - 16M sectors or 0.5MB - 8GB), especially when the disk is actually busy.

BTW: is the hardware disk cache on or off in the IPEAK SPT tests? If it's on, then why are we seeing considerable time spent on seeks between 512 and 16M sectors if they should be cached? If it's indeed off, well, that's good to know and can we also see the times with the cache on?

There are no if-ands-or-buts about it. If the graph says it was cached, it was cached. No matter where on the disk it was. If you understood how IPeak worked you'd know that.

Your assumption that it doesn't make sense for accesses on opposite ends of the disk to be cached by read-ahead algorithms again betrays a lack of basic understanding. I'll explain quickly. Single-user (desktop) accesses are localized --highly localized as the data Eugene showed indicates. This means they are more likely to be close to previous accesses (in fact they're in little patches all over the disk). If you consider this, it should be easy for you to understand how a bunch of requests all the way across the disk could be cached --they were right beside a previously accessed area. It is this characteristic of desktop workloads that allows the disk cache to be the dominant performance influence --mitigating the importance of access time. It doesn't matter if the requests are far apart on the disk if they are simply alternating between recently accessed areas of the disk. If you're just seeking back and forth between different spots, most of those requests will be caught up in the cache no matter how great the seek distance is.

P.S. I already said the disk cache is on.

The graphs clearly state "Read Seek Profile" so I naturally ignored rotational latency. So what are the graphs really meant to show? Seek latency? Rotational latency? Or both?

If you read the introduction to the graph you'd see it talks about random access performance :unsure:. But forget that, look at the graph. Understand what it's showing. It's called "Read Seek Profile" because the independent variable is the seek distance. The dependent variable is time. Clearly we're counting time against read seek distance. Why would rotational latency not be included on the dependent variable? Just because the independent variable is seek distance and the graph is named after the independent variable (as is common practice in many cases)? Besides the giant, flat, red band, unchanging across a long range, should have been a big red flag...

Anyway, I'm not trying to be insulting nor condescending. I just want to make sure that you understand that you are overlooking basic things that Eugene, and some others, are so used to considering that maybe, in the future you might want to do a little more research before you jump into a discussion, or start accusing people who have clearly done their fair share of research that they're wrong. There were numerous ways you could have caught your mistake with that graph.

BTW: I'm an infrequent visitor to the SR website so I'm not familar with the test methodology used here. I stumbled upon this discussion from the main page link and I'm just saying what I feel might be wrong. After all I guess the forum is meant to stimulate discussion rather than follow what the authoritative say. I apologize if my words are offensive.

They are meant to stimulate discussion, but in most cases, if you don't know something, it's very likely you can answer your qestions without even asking them. No offense, but it's common sense and common consideration to do some basic research before you question someone else's conclusions. When you engage in a discussion, you need to be prepared for it otherwise all sorts of unfortunate thngs happen (impatience, grumpiness, misunderstandings over the units of graphs, and other things, et cetera, et cetera).

Every question I just answered, and answered above, you could have answered yourself in a couple minutes of research. It's always best, on discussion boards of any kind, to do some quick research to see if the knowledge you seek is available without bothering anyone else about it. Here's an essential internet resource, that you may or may not be familiar with considering your apparently-more-than-casual-knowledge of GNU/Linux. It's dedicated to asking questions to programmers, but it is common sense for asking any sort of question to any sort of community at all.

I don't want to discourage you from discussing things, I just want to encourage you to discuss things well.

Share this post


Link to post
Share on other sites

OK, Gilbo, so in the tests, the hardware disk cache is on, but the OS cache is bypassed, is that right?

Looking at the "Percentage Time Spent vs Seek Distance" graph and the comments below it:

"Again, just eyeballing results, the aformentioned 11% of requests that have to stride 8 gigabytes or more occupy about 25% of the disk's time. The remainder is either sequential, buffered by the drive, or a minimal distance away from the previous request."

I think I still fail to understand why the seeks between 512 and 16M sector would be "either sequential, buffered by the drive, or a minimal distance away from the previous request". Buffered? By whom? The hardware disk cache? You just said the hardware disk cache is already on. Then why are we seeing considerable time spent on these seeks if they are buffered? Would they be buffered by the OS disk cache? Maybe some of them, but not all. So why should we ignore these seeks (while they represent another 50% of the total time) when calculating the potential improvement?

I hope I've made my point clear and please answer my question directly.

Share this post


Link to post
Share on other sites

Back to the original question of how to get the snappiest possible response times... The answer depends on what the bottleneck in your system is. You will get the best answers if you post a description of your hardware and operating system. Personally, I would be very surprised if it is your disk. For most people, the best way to improve response times is to increase the amount of memory on the system up to 4GB and also using faster memory with less latency. Increasing the amount of memory on the system speeds *everything* up, including (surprisingly enough) level load times. When you load a level, your computer reads a lot of data from the disk and then has to find somewhere to save the data already in memory, which means it has to write to disk at the same time. More memory means less swapping means faster response. Some other things that can help are running more than one cpu, getting a faster disk, getting a faster network connection, and upgrading your operating system. If you run more than one disk-intensive processes at the same time, you will get a big speedup from using scsi disks instead of pata/sata disks, although that can be frightfully expensive. Without knowing more, I'd recommend that you load up your system with memory. You won't be disappointed.

Share this post


Link to post
Share on other sites

The hdd caching cannot be turn off. It is a locked feature of the hdd. It has its own algorithm method of caching data and loaded and optimise in the factory. The optimise algorithm varies from different manufacturer and models to achieve best results with minimum tradeoff.

Edited by AforceII

Share this post


Link to post
Share on other sites

If i am going to buy a fast and responsive hdd, i will not be looking at access times alone. I will be looking at the SR drivemarks and gaming tests comparison of hdds. They are more a true reflection on the hdd. However if i am looking for a fast copying hdd for large DVD GB videos, i will be looking at a different set of review benchmarks which focus on copying.

Thats why reviewer like eugene spent hrs on different benchmarks to give good, bad and tradeoff of tested hdds to suit different applications needs. Even to the indept point of showing what the hdd is doing using Ipeak spt. All this helps in choosing a hdd to suit your needs.

Share this post


Link to post
Share on other sites
For most people, the best way to improve response times is to increase the amount of memory on the system up to 4GB and also using faster memory with less latency. Increasing the amount of memory on the system speeds *everything* up, including (surprisingly enough) level load times. When you load a level, your computer reads a lot of data from the disk and then has to find somewhere to save the data already in memory, which means it has to write to disk at the same time. More memory means less swapping means faster response. Some other things that can help are running more than one cpu, getting a faster disk, getting a faster network connection, and upgrading your operating system.

If by "upgrading your operating system" you mean, for example, switching from Windows to Linux, yes.

I've found that the memory management policy in Windows XP is (a) abominable and (B) not sufficiently tunable. Mainly, the MM is always trying to flush idle pages out, regardless of whether there is actually any memory pressure. The result of this policy is that on my system with 2GB RAM installed, 1.3GB is free most of the time, but whenever I switch from one app window to one that has been idle for 30 seconds or more there is a huge delay as Windows pages in the memory for the other app. This despite the fact that there is sufficient free RAM to keep all the apps completely in-core.

As another example of the wonders of the Windows OS - it takes about 45 minutes to compile the Mozilla source tree on my WXP system, using gcc. However, if I fire up VMware with a Linux guest on this same machine, with only 768MB of RAM dedicated to the VM, and compile the same source base with gcc under Linux, it takes only 7 minutes. Despite all the overhead of VMware emulating the hardware, the Linux cache manager is just so much better at using available memory that the performance hit of doing emulated I/Os is totally mitigated.

More RAM is only helpful if your OS is smart enough to use it. Microsoft Windows XP is not.

Speaking of which, I would love to see a code compile job included in the disk benchmark suite. That would be a real world test of cache effectiveness and seek times that would really mean something to me, anyway. Developers may be the stark minority in the audience, but it would still be a useful measure of disk performance, I think.

Share this post


Link to post
Share on other sites

What is really amazing to me on this whole post so far is the colours used in Eugene's graphs. There is one truth people and this is it! If you want more performance by a faster RPM drive: simply put: if i have a 15K RPM drive, it will be faster than a 7.2K RPM drive. The rest really does not matter!!!...

SCSA

Share this post


Link to post
Share on other sites
What is really amazing to me on this whole post so far is the colours used in Eugene's graphs. There is one truth people and this is it! If you want more performance by a faster RPM drive: simply put: if i have a 15K RPM drive, it will be faster than a 7.2K RPM drive. The rest really does not matter!!!...

SCSA

That is just so incredibly wrong. So much useful information in this post that was apparently just lost...

http://www.storagereview.com/php/benchmark..._1=283&devCnt=2

Share this post


Link to post
Share on other sites

About seek time, I agree with the others, it's not really as relevent. Especially considering most seeks are faster than the average. I mean with my Seagate 160GB, all the data is on the first 1/4 of the drive, so seek time can't be very substantial for me.

Share this post


Link to post
Share on other sites

What is really amazing to me on this whole post so far is the colours used in Eugene's graphs. There is one truth people and this is it! If you want more performance by a faster RPM drive: simply put: if i have a 15K RPM drive, it will be faster than a 7.2K RPM drive. The rest really does not matter!!!...

SCSA

That is just so incredibly wrong. So much useful information in this post that was apparently just lost...

http://www.storagereview.com/php/benchmark..._1=283&devCnt=2

You cannot take just any SR test and try to prove what i am saying is wrong. See, people seem to forget some things! If i can go faster, one can do more in less time. Just think of how mission critical servers would perform if all they had was 7.2 k drives. I think it is worth noting that yes, some home drives (7.2K) are faster in some thingsl but overall, 15 K rulez!!!...

SCSA

Share this post


Link to post
Share on other sites

Simple equations..

* Higher RPM = Lower Seek Times

* Higher Platter Density = Better STR

* Bigger Cache = Slightly Better Performance

Overall, we can't win them all.. Also the overall drive firmware coding also affects some performance characteristics. 10Krpm and 15Krpm drives rules with the best seek times. However, not nescessarily will win in overall performance category. A good combo is needed.. higher rpm, higher density platter and bigger cache would be "ideal". Not forgetting the hardware setup as well.. ;)

Share this post


Link to post
Share on other sites
Guest Eugene
I've always wanted to know the performance hit when AAM is enabled. Has this already been included in the testbench?

We will formally present results next month. Ballpark, however, its about a 10% real world slower.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now