Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and NFSv4.1/pNFS

Transcription

1 4479 Technical Report Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and Bikash Roy Choudhury, NetApp October 2013 TR-4239 Abstract Superior chip-verification performance is a requirement to complete design jobs in the compute farm and to speed time to market. This document focuses on improving Synopsys VCS build and verification performance during logical design processes over Network File System (NFS) version 4.1/parallel NFS (pnfs). NFSv3 is the most popular protocol used in the EDA space. It has been followed by NFSv4 and now NFSv4.1, which is a minor version of NFSv4. pnfs is part of NFSv4.1. The NetApp clustered Data ONTAP 8.2 operating system supports. This paper illustrates performance validations for VCS workloads over compared to those of traditional NFSv3.

2 TABLE OF CONTENTS 1 Introduction Target Audience Parallel NFS (pnfs) Compute Farm Optimization NFSv3 and Can Coexist in the Compute Farm Best Practices for Compute Nodes Synopsys VCS Performance Validation with Clustered Data ONTAP Performance Validation Objectives NetApp EDA Test Lab Details Test Plan NetApp EDA Lab Test Results How Does with Delegations Improve Performance? What Do These Improvements Signify? Conclusion LIST OF FIGURES Figure 1) pnfs implementation. Figure 2) Configuring the delegation on the DNS server. Figure 3) Adding the LIF IP addresses for hostname vcs. 2 Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and

3 1 Introduction Designing semiconductor chips has become increasingly complex because the chips have shrunk in size and at the same time perform much more complex processing with very low power consumption requirements. The complexity has led to a greater number of long-running design verification jobs to improve quality. These complex verifications require high performance to complete faster and to shorten the chip-design process, improving the overall efficiency of the verification tools used in the verification process. The process for optimizing clustered Data ONTAP 8.2 for Synopsys VCS workloads is documented in TR This document for the first time explores the benefits of using Network File System (NFS) version 4.1 and the parallel Network File System (pnfs) with Synopsys VCS. NFSv3 is the most commonly used protocol in the EDA space to date because of its robustness and performance capabilities. However, no further enhancements are being made to the NFSv3 protocol. NFSv4, the next generation, provides many new features, in addition to being more stateful than NFSv3. The new features include: Compound operations to batch RPC calls between the client and the server in a single I/O operation. Delegations for aggressive caching on the clients. Access Control Lists (ACLs) to provide Windows -like security for files and directories. Kerberos is more fine grained in the NFSv4 protocol and user authentication is much more robust. Ancillary protocols like Portmap, MOUNTD, Network Lock Manager, and Network Status Monitor that are found in NFSv3 no longer exist in NFSv4. There is only one NFS port 2049 to manage. This makes firewall administration a lot easier. The transport layer always uses the Transport Communication protocol. The User Datagram protocol, which was present in NFSv3, is no longer supported in NFSv4. Locking is more lease-based between the client and the server. There are no ancillary locking protocols in NFSv4. Refer to TR-3580 and TR-4067 for more information on NFSv4 and setting it up with clustered Data ONTAP 8.2. NFSv4 was designed for more reliability, security, and cache correctness and not for performance. NFSv4.1, the minor version that followed, has all the features of NFSv4 and includes pnfs, which is designed for performance. However, not all workloads benefit from pnfs. A thorough Synopsys VCS workload analysis was done before validating the performance over. 2 Target Audience The content of this paper targets independent software vendors in the EDA space who make chip-design tools and also semiconductor companies that use these tools for chip design and manufacturing. The best-practice recommendations in this document for running Synopsys VCS over and NetApp clustered Data ONTAP 8.2 will benefit both groups because logical verification will be able to complete faster. 3 Parallel NFS (pnfs) NFSv3 has been very popular and is the de facto protocol required by most EDA applications. This protocol has generally met the performance needs of most EDA applications to date, and NFSv4 was not developed as a performance play. This version of NFS is more of a security and reliability play because it provides features including Kerberos, Access Control Lists (ACLs), and delegations. However, performance as well as security and reliability are achieved with NFSv4.1 file delegations and pnfs. 3 Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and

4 pnfs is an extension of the minor version NFSv4.1. Unlike NFSv3, NFSv4, and NFSv4.1, which have metadata and data on a single I/O path, pnfs isolates the metadata from the data. pnfs consists of two main components: Metadata server (MDS) This server handles all metadata operations like GETATTRs, ACCESS, LOOKUPs, SETATTRs, and file layout information. Data server (DS) This server stores all the inode information and the real data. The clients have a direct path to access the data server. The following figure shows how a pnfs client communicates with the metadata server and the data server. The figure on the right illustrates how pnfs is implemented in clustered Data ONTAP 8.2. pnfs is purely a clustered Data ONTAP implementation. Data ONTAP operating in 7-Mode does not support pnfs. For more details on pnfs refer to TR Figure 1) pnfs implementation. Figure 1 has two pictures. The picture on the left shows the generic pnfs implementation in which a pnfs client communicates with the metadata server to get file location information. File layout information is sent out to the client from the MDS that hands out the location of the file in the data servers and also the information on the network path to get to that location. The control protocol provides synchronization between the MDS and the DS. The picture on the right in Figure 1 illustrates that every node in clustered Data ONTAP is a metadata server and a data server. If any LIF IP address in the SVM is mounted by the pnfs client, that cluster node becomes the MDS for that client. If a data volume is located in that cluster node or any other node in the cluster namespace that corresponding node becomes the DS. Eventually the pnfs clients can reach the data volumes that are located in the cluster namespace through a local data path. NetApp only uses pnfs over files. Clustered Data ONTAP uses pnfs over files and not over blocks or objects. Enable with Delegation in Clustered Data ONTAP 8.2 Clustered Data ONTAP 8.2 supports NFSv4.1 file delegations. The following options need to be enabled on the SVM to use with read and write delegations. nfs modify -vserver vs1_eda_vcs -v4.1-pnfs enabled -v4.1-readdelegation enabled -v4.1-write-delegation enabled has client dependency. RHEL6.4 is now the GA version that supports pnfs over files. Clustered Data ONTAP 8.2 is optimized to perform better with RHEL6.4 over NFSv3 and with file delegations enabled. Section 5 provides more information on the performance validation that was completed in NetApp s EDA lab. 4 Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and

5 is a step in the right direction for handling the growing performance demands of VCS workloads, specifically in the verification phase. Newer versions of Synopsys VCS support the 64-bit architecture and the most recent VCS version is qualified on RHEL6.4. A parallel file system like pnfs with clustered Data ONTAP can achieve the high concurrency and performance requirements of the VCS application and provide faster job completion times over NFSv3. The performance details are discussed in Section 5 Synopsys VCS workloads always consist of a high amount of metadata. In a traditional NFSv3 setup a single controller gets bottlenecked due to high metadata operations. pnfs isolates the metadata from the data on a single I/O path. An innovative way involving on-box DNS round robin was used to spread the metadata over all the controllers in a cluster setup. As mentioned earlier, any LIF IP address mounted by the client identifies that cluster node as the metadata server. Using the on-box round robin feature, clients in the compute farm can mount the LIF IP address assigned by the storage in a round-robin manner, thus making every cluster node in the cluster setup function as a metadata server. On-Box DNS Round Robin Clustered Data ONTAP 8.2 provides the ability to leverage the named service on each node to service DNS requests from clients and issue data LIF IP addresses based on an algorithm that calculates CPU and node throughput to provide the least utilized data LIF. This enables proper load balancing across the cluster for mount requests. Once a mount is successful, the client continues to use that connection until remount. This differs from round-robin DNS because the external DNS server services all requests and has no insight into how busy a node in the cluster is. Rather, the DNS server simply issues an IP address based on which IP is next in the list. Additionally, round-robin DNS issues IP addresses with a time to live (TTL). This caches the DNS request in Windows for 24 hours by default. On-box DNS issues a TTL of 0, which means that DNS is never cached on the client and a new IP is always issued based on load. On-Box DNS Round-Robin Configuration The following steps illustrate the way to configure on-box DNS round robin on clustered Data ONTAP 8.2 and the Windows 2008R2 DNS server. Clustered Data ONTAP 8.2 The following example consists of a four-node FAS6280 cluster. The SVM vs1_vcs_eda spans all four cluster nodes. Four LIF IP addresses are configured for this SVM. Each cluster node has a LIF IP address configured on its home port. FAS6280-svl FAS6280-svl FAS6280-svl FAS6280-svl The Windows 2008R2 DNS server IP address is Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and

6 Enable the LIFs to Query the DNS Server Verify that the DNS is configured correctly on the SVM. Refer to TR-4067 to configure DNS on clustered Data ONTAP 8.2. bumblebee::*> vserver services dns create -vserver vs1_eda_vcs -domains eda.local.com -state enabled -timeout 2 -attempts 1 -name-servers , bumblebee::*> dns show (vserver services dns show) Name Vserver State Domains Servers vs1_eda_vcs enabled eda.local.com, , eda-win-1.eda.local.com Configure the LIFs to query the DNS server. This is a new capability in clustered Data ONTAP 8.2. bumblebee::*> net int show -vserver vs1_eda_vcs -fields address (network interface show) vserver lif address vs1_eda_vcs vs1_eda_vcs_data vs1_eda_vcs vs1_eda_vcs_data vs1_eda_vcs vs1_eda_vcs_data vs1_eda_vcs vs1_eda_vcs_data entries were displayed. bumblebee::*> net int show -vserver vs1_eda_vcs -fields dns-zone,listen-fordns-query (network interface show) vserver lif dns-zone listen-for-dns-query vs1_eda_vcs vs1_eda_vcs_data1 vcs.eda.local.com true vs1_eda_vcs vs1_eda_vcs_data2 vcs.eda.local.com true vs1_eda_vcs vs1_eda_vcs_data3 vcs.eda.local.com true vs1_eda_vcs vs1_eda_vcs_data4 vcs.eda.local.com true 4 entries were displayed. Windows 2008R2 DNS Server From the DNS manager create a new delegation for hostname vcs. Do not append the fully qualified domain name (FQDN). The DNS server will append that automatically. 6 Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and

7 Figure 2) Configuring the delegation on the DNS server. Add the four IP addresses (listed in this example) one by one to host the delegated zone. Figure 3) Adding the LIF IP addresses for hostname vcs. 7 Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and

8 Resolving vcs to Different IP Address Using On-Box DNS Round Robin C:\Users\Administrator>nslookup vcs Server: localhost Address: Non-authoritative answer: Name: vcs.eda.local.com Address: C:\Users\Administrator>nslookup vcs Server: localhost Address: Non-authoritative answer: Name: vcs.eda.local.com Address: C:\Users\Administrator>nslookup vcs Server: localhost Address: Non-authoritative answer: Name: vcs.eda.local.com Address: C:\Users\Administrator>nslookup vcs Server: localhost Address: Non-authoritative answer: Name: vcs.eda.local.com Address: C:\Users\Administrator>nslookup vcs Server: localhost Address: Non-authoritative answer: Name: vcs.eda.local.com Address: C:\Users\Administrator> 8 Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and

9 Mounting on the Compute Nodes Due to the on-box DNS round robin, compute nodes will mount a different IP address each time they mount the chip-design volume(s) using the hostname vcs. Node 1: vcs:/cmuservol on /cmuser-pnfs type nfs (rw,bg,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,vers=4,minorvers ion=1,clientaddr= ,addr= ) Node 2: vcs:/cmuservol on /cmuser-pnfs type nfs (rw,bg,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,vers=4,minorvers ion=1,addr= ,clientaddr= ) Follow these best practices for better manageability and performance. Best Practices Enable read and write file delegations for NFSv4.1 to promote aggressive caching. pnfs provides data locality. The volume can be accessed over a direct path from anywhere in the cluster. There is no requirement to have a 1 LIF: 1 volume ratio for with delegations compared to the recommendation made in section 6.4 of TR-4238 for NFSv3. If a volume is moved for capacity or workload balancing, there is no requirement to move or migrate the LIF in the cluster namespace to provide local access to the volumes. NFSv4.1 is a stateful protocol compared to NFSv3. If there is ever a requirement to migrate a LIF, the I/O operations will stall for 45 seconds to migrate the lock states over to the new location. 4 Compute Farm Optimization The engineering compute farms in an EDA environment consist of tens of thousands of cores that would translate into hundred to thousands of physical compute nodes. Virtualization is usually not deployed in these farms and Linux is the most commonly used operating system in them. Linux clients in the compute farm provide the number of cores that are required to process the number of jobs submitted. For better client-side performance with clustered Data ONTAP 8.2, run the VCS application and schedulers such as Sun Grid Engine or Load Sharing Facility on Red Hat Enterprise Linux (RHEL) 5.7 and later or RHEL6.4 and later. Use the RHEL6.4 kernel for in the compute farm. RHEL6.4 has more optimization in the TCP stack to handle NFS requests compared to the earlier version. RHEL6.4 is also a GA version for pnfs support for files. Pre-RHEL6.4 versions are not qualified to run. Clustered Data ONTAP 8.2 and RHEL6.4 have been tested and validated by NetApp s NFS Engineering QA team along with Red Hat NFS Engineering. A lot of bugs were jointly scrubbed and fixed on the RHEL6.4 kernel and on clustered Data ONTAP 8.2 as well. For more details refer to TR The RHEL6.4 GA kernel does not have all the bugzilla fixes. Perform a yum update that downloads the latest.bz stream from Red Hat Network, which has fixes for almost all of the known issues. Once the kernel is updated, the new kernel should show as el6.x86_64. Note: RHEL6.5 releasing in November 2013 will include all the bug fixes in the kernel by default. There is no requirement to perform a yum update to download the patch for the Clustered ONTAP bug fixes. 9 Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and

10 4.1 NFSv3 and Can Coexist in the Compute Farm It is not easy to upgrade hundreds of compute nodes to RHEL6.4. RHEL6.4 can be added as a new deployment in the compute farm after this release is qualified to use in your environment. The file system exported from clustered Data ONTAP 8.2 can be mounted on various different Linux kernels in your compute farm. All your pre-rhel6.4 clients can continue mounting the file system over NFSv3 and the same file system can also be mounted over on the RHEL6.4 clients. This means that NFSv3 and can coexist in the compute farm for one or more exported file systems. EDA tool vendors such like Synopsys has already qualified RHEL6.4 and provide supportability for the latest VCS release. NetApp is also encouraging other tool vendors to support RHEL6.4 and later versions of the kernel for different EDA applications. Once RHEL6.4 is qualified by EDA vendors for their applications to support x86_64-bit kernels, will be another protocol to use in the VCS environment. The benefits of having both NFSv3 and NFSV4.1/pNFS protocols coexist in the compute farm are the following. No change is required to existing compute nodes that mount the file systems over NFSv3. There is no disruption to existing clients in the compute farm as more nodes on RHEL6.4 are added to scale the number of jobs. The same file system can also be mounted over NFSv3 or from new pnfs-supported RHEL6.4 clients. Based on the performance validation documented in Section 5, definitely provides significant performance improvement in job completion times. Critical chip designs can be isolated from the rest to provide faster job completion and better SLO. 4.2 Best Practices for Compute Nodes Considering the high volume of nodes in the compute farm, it is not realistic to make significant changes dynamically on each of the clients. Based on the VCS workload evaluation, the following recommendations on the Linux clients greatly improve job completion times for various chip-design activities. Compute Node Optimization Turn off hyperthreading on the BIOS setting of each of the Linux nodes. Use the recommended mount options while mounting over NFSv4.1 on the Linux compute nodes. vers=4,rsize=65536,wsize=65536,hard,proto=tcp,timeo=600,minorversion=1 Set the net.core.netdev_max_backlog = ; avoid dropped packets on a 10GBe connection. Set the ntp or time server on all of the compute nodes. [root@ibmx3650-svl50 /]# ntpdate -q server , stratum 3, offset , delay Jul 12:55:59 ntpdate[1567]: step time server offset sec [root@ibmx3650-svl50 /]# ntpdate Jul 12:56:52 ntpdate[1568]: step time server offset sec [root@ibmx3650-svl50 /]# chkconfig ntpdate on [root@ibmx3650-svl50 /]# service ntpd restart Shutting down ntpd: [FAILED] Starting ntpd: [ OK ] 10 Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and

11 5 Synopsys VCS Performance Validation with Clustered Data ONTAP 8.2 With increasing Cluster-Mode adoption in the EDA space, it is very important that our customers learn of the recommendations and best practices required for VCS workloads. The performance results mentioned in this section made use of all the recommendations and best practices listed in this paper. Synopsys VCS application performance was validated in the NetApp EDA lab. Because of its partnership with Synopsys, NetApp was able to obtain the licenses to run the tool on an OpenSPARC chip design. The test results from the NetApp EDA lab demonstrated consistent improvements with the optimizations made to clustered Data ONTAP 8.2, the network, and the compute nodes. 5.1 Performance Validation Objectives The primary objectives of Synopsys VCS performance validation with clustered ONTAP 8.2 are the following. Validate that the Synopsys VCS job completion time on clustered Data ONTAP 8.2 is on par with Data ONTAP Mode over NFSv3. TR-4143 highlights a 20% overall improvement with Data ONTAP 7-Mode. Explore new technology like pnfs for VCS workloads. Validate that the VCS job completion time with clustered Data ONTAP 8.2 over pnfs is comparable to or better than that of Data ONTAP Mode over NFSv3. Enable reduction in job completion time, allowing users to move on to other chip designs and more optimally use their license, thereby improving the ROI of the VCS tool. 5.2 NetApp EDA Test Lab Details The NetApp EDA lab consists of 15 physical compute nodes. Each compute node has 8 cores and 32GB of physical memory with a 10GB connection to the storage through a 10GB switch plane. The tests were able to scale up to 120 cores. All of these computes run on RHEL6.4 kernel el6.x86_64. Sun Grid Engine v6.1 was used as the scheduler to submit the jobs in the compute farm. Synopsys VCS v11.3 was used for this test. On the storage side we had a four-node FAS6280 cluster with 10GB data ports. Each cluster node had two 10GB data ports aggregated to provide 20GB network bandwidth that can provide up to 2.4GB/sec throughput. Each of the cluster nodes had four shelves of 15k RPM SAS disks. Each cluster node had 512GB of a PCIe-based Flash Cache card. For the 7-Mode setup a single FAS6280 HA pair was used with two 10GB data ports aggregated, four shelves of 15k RPM SAS disks, and 512GB of a PCIe-based Flash Cache card on each controller. Both the clustered and 7-Mode setups were tested on Data ONTAP Test Plan The OpenSPARC chip design was used to run the various tests on NetApp storage to generate the workload with the VCS tool. Although the VCS builds generated an appreciable amount of workload, the VCS simulation was modeled to stress the storage. Four different sets of tests were performed. Synopsys VCS build and verification tests over NFSv3 with Data ONTAP Mode. This setup was completely optimized based on the recommendations documented in TR This test was considered as the baseline for the tests that followed. Synopsys VCS build and verification tests over NFSv3 with clustered Data ONTAP 8.2 fully optimized. Synopsys VCS build and verification tests over NFSv3 with FlexCache on clustered Data ONTAP 8.2 fully optimized. Synopsys VCS build and verification tests over with delegations on clustered Data ONTAP 8.2 fully optimized. 11 Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and

12 Note: The clustered Data ONTAP 8.2 optimization was done based on the recommendations documented in this paper. 5.4 NetApp EDA Lab Test Results The NetApp EDA lab yielded up to a 19% improvement for builds and a 26% improvement for builds over pnfs compared to results from NFSv3 from Synopsys VCS performance validation tests. The build and verification jobs were scaled up to 120 cores. The following figure highlights the performance improvement in the VCS build tests. Figure 4) Synopsys VCS build time improvements. From Figure 4, Synopsys VCS build times are comparable for Data ONTAP Mode and clustered Data ONTAP 8.2 over NFSv3. The builds take a longer time to complete with FlexCache configured and accessed over NFSv3 due to the high number of writes that occur while creating the database and linking process. FlexCache is normally used as a read-only or read-mostly cache. For more use cases refer to Section 7.1 in TR The best results were obtained when tests for VCS builds were run over with delegations. There was a 19% overall build time improvement with pnfs compared to results for tests run over NFSv3 in an identical test environment. The NetApp EDA lab achieved a 26% improvement for VCS verification workloads over pnfs compared to results over NFSv3. The verification workload was modeled to generate the load to stress the storage. The different tests were run in isolation to come up with the right set of recommendations and best practices to optimize the overall verification workload. The following figure illustrates the results obtained from tests run with various verification workloads. 12 Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and

13 Figure 5) Synopsys VCS verification test scenarios. The performance numbers definitely demonstrated that the reads were on par with or better than those of Data ONTAP Mode over NFSv3 although there were instances in which writes could have improved in clustered Data ONTAP 8.2. Tests have indicated that clustered Data ONTAP 8.2 has shown about 10% improvement for writes over results with clustered Data ONTAP 8.1.x. FlexCache again shows that it is not a good fit with verification workloads because of the large amount of writes going through the cache. However, Section 7.1 in TR lists other use cases in which FlexCache can be deployed. with delegations has definitely proved to be a winner with verification workloads. There is about a 26% improvement compared to the results of VCS verification tests performed over NFSv3 with Data ONTAP Mode. 5.5 How Does with Delegations Improve Performance? The following points describe why job completion times improve over with delegations enabled. NFSV4.1/pNFS with delegations helped to improve response time for the jobs submitted in the compute nodes. NFSv4.1 read delegations cache data locally on the compute nodes. This allows the data to be accessed locally on the compute nodes. There is no requirement to have SSDs or a server-side cache card on the compute nodes. There is a considerable reduction in RPC calls through compound operations compared to those with NFSv3. Synopsys VCS workloads have a large amount of metadata. NFSv4.1 delegations and pnfs help to reduce the amount of GETATTRs, which helps to reduce latency. The workload sample that was tested in the NetApp EDA lab had 9 million GETATTRs over NFSv3; this was reduced to 58,000 over. This significant reduction in the number of GETATTRs improves response time. NFSv4.1 delegations and pnfs reduce the amount of GETATTRs compared to the number with NFSv3. The RHEL 6.4 client does not generate additional GETATTRs with delegation in the pnfs metadata path. The pnfs data path does not have any GETATTRs overhead. 13 Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and

14 There are not too many write threads to a single file. This means that writes go to different files, which helps to improve the effectiveness of NFSv4.1 write delegation. A local data path is provided to access volumes anywhere in the cluster namespace. When write sizes are larger, performance is better, particularly when writing large sequential log files during regression. 5.6 What Do These Improvements Signify? As mentioned earlier, the verification process is getting more complicated and time consuming. From our test results we can infer that there is a 23% overall improvement in VCS build and verification with clustered Data ONTAP 8.2 over NFSv4.1/ pnfs with delegations compared to results with Data ONTAP Mode. This implies that with clustered Data ONTAP 8.2 over pnfs there is an overall job completion time improvement of 1.3x over Data ONTAP 8.1.x 7-Mode with the NFSv3 baseline (refer to TR-4143). Jobs that would have taken 30 weeks now complete in about 23 weeks. The potential reduction of about 7 weeks in job completion time significantly impacts ROI and time to market. The improvement in the job completion time is a clear indicator that adequate optimization at the storage, network, and compute nodes can enhance the overall productivity of the chip-design process. No tuning is required with Synopsys VCS to improve job completion time. Many variables also contribute to improvement in wall clock (elapsed) time. The amount of improvement will vary considerably based on the design type. Tests have identified that job completion times improved for chip designs when the delta between the wall clock and the user time was higher. There may be no improvement for designs when the wall clock time is equal to the user time. Performance validations also have indicated that shorter jobs improve with optimization (a higher percentage of overall job time spent in I/O processing). 6 Conclusion Exploring and validating new technologies such as and finding ways to improve job runtime performance have always been an ongoing process. Although we originally set out to match clustered Data ONTAP 8.2 performance with that of Data ONTAP Mode, we ended up achieving improvements up to 26% for verifications and 19% for builds with. These improvements provide huge benefits over those provided with 7-Mode. Our tests indicate that withadequate sizing and tuning of storage and compute nodes using, the VCS job completion time is 1.3x times faster than that of the Data ONTAP 8.1.x 7-Mode baseline. NFSv4.1 accelerates Synopsys VCS verification time for faster time to market with the parallel network file system. 14 Synopsys VCS Performance Validation with NetApp Clustered Data ONTAP 8.2 and

15 Refer to the Interoperability Matrix Tool (IMT) on the NetApp Support site to validate that the exact product and feature versions described in this document are supported for your specific environment. The NetApp IMT defines the product components and versions that can be used to construct configurations that are supported by NetApp. Specific results depend on each customer's installation in accordance with published specifications. NetApp provides no representations or warranties regarding the accuracy, reliability, or serviceability of any information or recommendations provided in this publication, or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS, and the use of this information or the implementation of any recommendations or techniques herein is a customer s responsibility and depends on the customer s ability to evaluate and integrate them into the customer s operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document. 15 Synopsys VCS Performance 2013 NetApp, Validation Inc. All with rights NetApp reserved. Clustered No portions Data of ONTAP this document 8.2 and may be reproduced without prior written consent of NetApp, Inc. Specifications are subject to change without notice. NetApp, the NetApp logo, Go further, faster, and Data ONTAP are trademarks or registered trademarks of NetApp, Inc. in the United States and/or other countries. Windows is a registered trademark of Microsoft Corporation. Linux is a registered trademark of Linus Torvalds. All other brands or products are trademarks or registered trademarks of their respective holders and should be treated as such. TR