WD DX4000: Intel RST 12.9 vs 13.1 performance and flashback

I recently had the opportunity to rebuild my system and decided to upgrade to Windows Server 2012R2. I like having a system that I know I can rely on, an “out of sight, out of mind” type deal; however, I do occasionally get way to involved and analytical while getting my hands dirty. Regardless of those things, the past week has been interesting and I thought I would share some of my findings related to this upgrade and the performance differences between the two currently available RST drivers from Intel.

[update: 10.23.2014, the RST CLI 13.1.0.1058 is now available from Intel to use with the corresponding drivers for array modifications]

Brief:

I’m still using the Western Digital DX4000 I purchased back in the fall of 2012 and after publishing my first series of articles on building up a 2012 system I’ll be honest, I hardly touched the damn thing for almost a year. There were a few times that I did need to get in to shut it down during a power outage; which could have been resolved with some UPS monitoring configuration, but that was basically it. So to date, the thing has been a “Steady Eddie” in my small home office.

 

Background:

With the release of Server 2012R2 comes a few updates, but today I’ll focus on just the subsystem and the latest RST drivers from Intel. There are a few things to mention that are potential headaches. The script that I created to send system vitals to the LCD does work; however, there are a few metrics that are a tad buggy at the moment. The NIC readings are not functioning correctly. I know the reason for this and plan to provide an update when I can. The cause is that with the update to 2012R2, there are currently no drivers available from Intel for the 82754L Ethernet adapters. Only the Microsoft drivers are available that are built into the installation, which also means that the teaming has to be done differently and so the WMI containers have probably changed. I’m using the Microsoft teaming features built into 2012R2, and honestly… it’s working just fine. I’m currently transferring approximately 1.2TB of data to it from my workstation with a peak receive rate of approximately 635Mbps on large files and a low rate in the range of 250Mbps to 300Mbps on mid-size files. I’ll probably leave it alone unless Intel produces some excellent drivers for the 82574L and Server 2012R2; however, I’m not holding my breath on that one.

 

Benchmarks:

I used the 12.9 Driver released for Windows Server 2012 to build the array in WINPE as they have the matching RST CLI command line tools that work in tandem. As such, I also used this driver for the auto unattended installation for server 2012R2. They worked just fine and I decided before upgrading them, that I would run some quick performance tests against the array.

Figure 1: 12.9 Driver Benchmark

 

Here are the results after upgrading the drivers to version 13.1 along with the management console.

Figure 2: 13.1 Driver Benchmark

Before I run the numbers, I want to also present a capture I made back in early January, 2013 of the Windows Server 2012 build using the 12.5 drivers.

Figure 3: 12.5 Driver Benchmark, 01/2013

It is not difficult to see some significant differences across the board from 12.5 to 13.1 drivers.

 

Disclaimer:

I need to make a disclaimer about some of the data, primarily in the fact that the measurements made with the 12.5 drivers back in 12/2012 and 01/2013 did not have any changes made to the subsystem. It was as it came from the factory, which I believe the array had a 64K stripe size and I think it had a 4K allocation unit. I could be wrong and it had a 64K allocation unit, I just do not know for certain as I did not log it at the time those metrics were made. Anyone willing to fire up a WINPE session and run a check on it? I’ll include some instructions at the end of this posting on how to verify it. The new subsystem for the 12.9 and 13.1 driver testing is using a 128K stripe size with a 64K allocation unit. Also note, the original 12.5 testing consisted of 4 drives in RAID 5, while the recent tests were done with only 3 drives in RAID 5. I’ll admit, this could have obvious impact on the reporting numbers. My tests against the older metrics are not relational due to the differences.

 

The Subsystem:

On that note, I’ll just mention the current subsystem configuration for the latest metrics and then I’ll provide the results and raw numbers.

I pulled a drive from port 1 and replaced it with a SSD for the EFI, System, and Windows installations. It provides a much better experience and usability while in a RDP session has been well worth the potential risk of losing the drive in case of a failure. This may not be a risk some folks are willing to take, and for the most part I would agree that in a heavy production sense, this may not be best idea in the world. I just want to say though, which is more important… making sure everything is reliable while sacrificing performance, or boosting performance while minimizing the risk? For me, the latter is worth it. Just if this thing had 5 bays, I could mirror the SSD and RAID 5 the storage and be in heaven.

One last note before I dive into the numbers, a good continuity plan is not a guarantee. It is only insurance that a well paved road to recoverability can be enacted. So, make a plan to recover and test it from end to end. For this system configuration, I need to ensure that after I have installed all my services, I have two things complete. A solid image of the original build, and a working Bare Metal Restore (BMR). I’m currently working on the second part of that, and should hopefully be able to yield some insights in a future article.

 

Results:

Ok, enough of the mumbo jumbo, let’s look over the raw data.

ATTO Benchmarks
 

12.5

12.9

13.1

12.5 vs 13.1 12.9 vs 13.1
Read MB/s          
512K

324.983

326.696

350.896

7.67%

7.14%

1024K

359.511

346.368

369.406

2.71%

6.44%

2048K

334.152

352.431

362.750

8.21%

2.89%

4096K

277.309

331.401

344.884

21.72%

3.99%

8192K

241.290

306.433

377.192

43.95%

20.70%

           
Write MB/s          
512K

162.360

180.561

205.697

23.55%

13.02%

1024K

151.373

189.039

194.518

24.95%

2.86%

2048K

145.362

189.930

194.989

29.16%

2.63%

4096K

155.165

189.930

193.119

21.79%

1.67%

8192K

139.326

186.413

201.075

36.28%

7.57%

 

The percentages are calculated differences between the variants. Well, what can I say except it’s’ all green for the 13.1 driver performance. It is surprising that the increase between 512K and 8192K transfers are so huge. The subsystem was identical on those measurements with a 128K stripe and 64K allocation unit size.

Figure 4: Read Performance

 

Figure 5: Write Performance

 

It is pretty clear, that modifying the subsystem to something not so generic can make a difference. The only way to improve the write performance is to move to a RAID 0 or RAID 1+0 configuration, which doesn’t seem to be an option on the DX4000. It could be that I was not using the CLI tool correctly, which is highly probable, but even getting a simple RAID 0 configured with two drives seemed impossible. It’s just a feature not made available to us. Let the sad faces and crying of small children ensue.

 

Conclusion:

I have nothing honestly, other than restating the obvious. I’d be curious to hear from anyone willing to run a check on their original DX4000 subsystem. To verify it, build yourself that bootable USB with WINPE, make note of the changes I presented this past week about inject the 12.9 drivers including the RST CLI.

When you execute the following command, the Volume Information section will note the stripe size value:

X:\RSTCLI\rstcli64.exe –information

–VOLUME INFORMATION–
   
Name: R5VOL0
Raid Level: 5
Size: 7452 GB
StripeSize: 128 KB
Num Disks: 3
State: Normal
System: FALSE
Initialized: FALSE
Cache Policy: WB

 

To check the allocation unit size, run DISKPART, select the disk, select the volume, and execute FILESYSTEMS:

DISKPART> FILESYSTEMS      
         
Current File System      
         
Type : NTFS      
Allocation Unit Size : 64K      
Flags : 00000000      
         
File Systems Supported for Formatting    
         
Type : NTFS (Default)    
Allocation Unit Sizes: 4096, 8192, 16K, 32K, 64K (Default)
         
Type : REFS      
Allocation Unit Sizes: 64K (Default)    
         

 

Happy reconfiguring… and good luck out there!

Advertisements
Tagged with: , , ,
Posted in WD DX4000
One comment on “WD DX4000: Intel RST 12.9 vs 13.1 performance and flashback
  1. […] You can read the full post here. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: