27 April, 2010

Trying to reach the highest disk speed on home server

Last autumn, before installing my Ubuntu home server I had great plans to do network file speed benchmarks between different operating systems to select the best operating system for my home server. The plan was excellent, but after a bit more than one month of testing I realized, that if I ever want to have that server up and running I should cancel these tests and go strait to the installation. In this post I will write about the results in that month.

Original intention

The plan was simple, I had the new hardware for the server, I had installation disks for Windows Server 2008 R2, Ubuntu, OpenSuse and Solaris. On the client side I had a quad processor 2 gig memory computer with Windows 7 RC, Windows XP and OpenSuse 11.1 and had an older computer with and old Athlon processor running at 2 GHz and 1 Gig of memory. So I intended to install all 4 server operating systems, test them from the 3 client operating system available on the faster client machine and from the XP on the slower machine. Altough you can measure a lot of different aspects of file operation speeds I just wanted to test the writing and reading of a 4 gig file (speed of copying large multimedia files).

In addition to these options I was planning to test stripped drives, iSCSI and NFS protocolls, to find the best combination.

Benchmarking problems

You may think that measuring file copy speeds is easy, but in the reality it is rather complicated.
Firts I started with IOZone, and excellent multiplatform disk IO benchmark tool. It was working well, but on Windows 7 in local disk benchmarks, when writing to disk, all the memory was eaten and the write speeds were very slow. On top of this it turned out, that when copying large files to a server, the robocopy command was significally faster, which was strange, because robocopy had to read a file from the disk, transfer it over the network and write it to the server disk, while IOZone didn't had to read from the local disk. (It turned out, that this is because Windows is "cheating" when using the built in copy or robocopy commands, it allocates the whole space needed on the server at the begining of the operation, while when IOZone and other programs are performing write opperations, the allocated space is increased several times which slows down the whole operation.)

So I have included a robocopy (dd in case of linux) benchmarks in the tests.

In addition to this I have found the DiskBench application, which did not overflow the memory of Windows 7 RC in local copies, but had a very slow performance on network writes. (I do not know why). Aside from this it is a very nice application.

In addition I have used an custom developed .NET application which did file write or read based on the command line parameters.

I always tried to create trustworthy results, but I never managed to do. Some of the test results were always unbeliveable, and then more I tried to figure out the source of the inaccuracy then less I could find a good explanation. (One example: I have attached an USB external drive to the server, which has a read speed limitation of about 25 Mbytes/sec. In one of the tests I managed to read at 43 Mbytes/sec measured at the client).

So lets see the results

In the colums you can see the results for the different clients, while each row represents a server configuration. The read and write values here are the average values of several measurements.

  • Windows 7 with Windows Server 2008 is performing pretty well
  • Stripped drives increase the internal speed, but have almost no visible effect on the client side
  • Windows XP performs much worse than Windows 7
  • SUSE Linux client is performing on pair with XP in CIFS file system, it is the fastest in NFS writes and it is in pair with Windows 7 on iSCSI
  • Ubuntu server has the same write speeds as Windows Server 2008, but the read speeds are only the half
I am sorry that I could not complete all the test, I think that it would be very interesting to see all the results, but I could get only this far in this journey.

No comments: