Disk benchmarking: IDE vs SATA on the guest

[socratis]

Motivated by a response I gave in a different thread, I run a disk benchmark test to see the differences between IDE and SATA controllers. The only change made in the VM was to remove the HD from the SATA controller and add it as a IDE primary master.
Host: MacBookPro early 2011, 16GB RAM, OSX 10.6.8.
Guest: Windows 8, up to date.

Code: Select all

-----------------------------------------------------------------------
CrystalDiskMark 3.0.3 (C) 2007-2013 hiyohiyo
                           Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

                                  IDE                             SATA
           Sequential Read :   621.102 MB/s                     52.542 MB/s
          Sequential Write :   102.121 MB/s                     40.168 MB/s
         Random Read 512KB :   591.980 MB/s                     23.917 MB/s
        Random Write 512KB :    69.883 MB/s                     24.321 MB/s
    Random Read 4KB (QD=1) :    27.846 MB/s [  6798.3 IOPS]      0.300 MB/s [    73.1 IOPS]
   Random Write 4KB (QD=1) :     1.415 MB/s [   345.4 IOPS]      0.742 MB/s [   181.2 IOPS]
   Random Read 4KB (QD=32) :    25.203 MB/s [  6153.0 IOPS]      0.402 MB/s [    98.2 IOPS]
  Random Write 4KB (QD=32) :     1.461 MB/s [   356.6 IOPS]      0.812 MB/s [   198.3 IOPS]

The differences are way too big to ignore. Anyone can explain what's going on? Are these number even close to being trustworthy?

[mpack]

I wouldn't trust those numbers, especially if you use a virtual timer as your stopwatch.

[loukingjr]

I didn't run a benchmark but switching the .vdi certainly made the guest I tried it with load faster.

[loukingjr]

there seems to be an unwelcome side effect however. I have an app that shows me how much memory is being used in my menubar. normally when I open a guest, whatever amount of memory is assigned to the guest is stable. however, when I switched the .vdi to IDE I can watch it use more and more memory at a rate of about 1% every 15 to 20 seconds or so.

edit: I may be mistaken about the memory issue. I'm doing further testing.

[socratis]

I wouldn't trust those numbers, especially if you use a virtual timer as your stopwatch.

I wouldn't know what a virtual timer would be in that case (or any other for that matter), but I believe I may have found the answer to my own question; it turns out that host I/O caching might be the root cause. From the manual:

Since asynchronous I/O is not supported by IDE controllers, for performance reasons, you may want to leave host caching enabled for your VM's virtual IDE controllers...
...For the above reasons also, VirtualBox now uses SATA controllers by default for new virtual machines.

Funny thing is that for IDE controllers the host I/O caching is enabled by default, while for SATA controllers it is not enabled by default. Why is that?

I re-run the same test (with a Win7 guest this time) and when I enabled the host I/O cache in the SATA controller, things got up to par with the IDE controller.

Code: Select all

                              IDE                   SATA                SATA w/caching

           Sequential Read :  826.43                53.01               838.59
          Sequential Write :  101.53                38.82                85.84
         Random Read 512KB :  796.65                24.26               923.11
        Random Write 512KB :   52.39                24.39                67.43
    Random Read 4KB (QD=1) :   33.87 [8269.4 IOPS]   0.35 [  85.6 IOPS]  25.94 [6331.9 IOPS]
   Random Write 4KB (QD=1) :    1.28 [ 312.9 IOPS]   0.73 [ 180.1 IOPS]   1.31 [ 320.0 IOPS]
   Random Read 4KB (QD=32) :   35.46 [8657.5 IOPS]   0.44 [ 107.6 IOPS]  33.32 [8135.5 IOPS]
  Random Write 4KB (QD=32) :    1.42 [ 346.4 IOPS]   0.74 [ 180.0 IOPS]   1.38 [ 336.8 IOPS]

Should I pro-actively enable host I/O caching in all my SATA controllers?

[loukingjr]

I have it enabled in all mine.

[socratis]

Hmm... Interesting. All my default templates have SATA I/O caching disabled and IDE enabled. May be it has to do something with my host's OS and/or hardware?

[loukingjr]

Hmm... Interesting. All my default templates have SATA I/O caching disabled and IDE enabled. May be it has to do something with my host's OS and/or hardware?

no, I enabled them all as I created the guests. sorry I wasn't clear. I was told when I first started using VB I should do that, so I did.

[dlharper]

Funny thing is that for IDE controllers the host I/O caching is enabled by default, while for SATA controllers it is not enabled by default. Why is that?

Thanks for noticing this. There doesn't seem to be any reason for it, but it does appear to be the case. I have enabled it in all my SATA-based VMs now.

[Perryg]

Faster doesn't always mean better. See http://www.virtualbox.org/manual/ch05.html#iocaching
I know from terrible experience that having IO Cache enabled has ( in the past ) caused real issues including corruption. I believe that it is for this reason that the DEVs have decided to not enable it by default in some guest receipts. They have said over and over there are real reasons why the have these default settings.

[loukingjr]

Thanks for the link Perry. I've only had a problem once with a guest failing after a power outage. Perhaps this is why.

[socratis]

I believe that it is for this reason that the DEVs have decided to not enable it by default in some guest receipts. They have said over and over there are real reasons why the have these default settings.

I couldn't agree more with you, both for the fast-vs-safe aspect, as well as the devs' wisdom. But, it doesn't make sense why it would be enabled for IDE controllers and not SATA ones. Maybe because most IDEs are "responsible" for CDs (=> read-only)? In any event, if you are on a laptop, or a decent UPS, the odds of catastrophic failure because of power loss are close to zero. Modifying my .vboxes as we speak...

[mpack]

I wouldn't know what a virtual timer would be in that case (or any other for that matter)

That would be a simulated timer, not necessarily running in real time. It makes real time benchmarks running inside the guest a bit iffy. You often see ridiculously high throughputs reported inside the guest for whatever task you time, because in fact a lot of the work is done by the host in the hosts timeslice. From the guests POV the throughput was infinite.

The details rather depend on how the guest OS tracks time.

The best timer to use inside a guest is a stopwatch in your hand, or better yet don't bother with benchmarks at all. They shouldn't be telling you anything you don't know already.