Comparison of ITTIA DB and SQLite

Transcription

1 Comparison of ITTIA DB and SQLite Table of Contents 1.Overview Performance Expectations Standard SQL Benchmark Test Environment Test Methodology Product Configuration Database Schema Parameters Test Algorithms Results Key Features Atomic Transactions Concurrency and Shared Access Data Typing and Type Safety Application Programming Interface Practical Storage Logic On-Disk File Storage In-Memory Storage High Availability Replication Device Notification Technical Support Conclusion...16 Copyright 2011 ITTIA, L.L.C.

2 1. Overview This white paper explores how the performance, feature set, and technical support for ITTIA DB SQL embedded relational database compares to that of SQLite, an open source database library. In a database-driven device application, the performance, scalability, and features of the embedded database will greatly impact the total cost of ownership (TCO) throughout development, deployment, and maintenance. ITTIA DB SQL is a software library to manage data stored in embedded applications and devices. Designed to be hidden from the end-user, ITTIA DB SQL links into the application or firmware as self-contained software libraries with no requirements for a dedicated database administrator. ITTIA DB SQL is a robust, scalable, and cross platform device database. 2. Performance Expectations ITTIA DB SQL empowers embedded applications through reliable and flexible data management that exhibits excellent performance characteristics under real-world workloads. The increasing requirement for data storage on embedded systems and devices poses a great challenge to application developers. On one hand, many developers consider using freely available software to reduce upfront cost. However, after investing months of time and engineering resources, requirements expand and they recognize the importance of performance, influence over database features, and access to one-on-one support from a real software company. Every software development project has unique requirements, including performance objectives, reliability expectations, and time-to-market constraints. Careful planning, and the incorporation of the right database technology, will dramatically reduce project development time while increasing the performance and reliability of an application. Market share is easier to capture when end-user expectations are met on time and within cost. Databases can be implemented in many different ways, and the choice of algorithms in a particular database product has a profound impact on performance characteristics and what features are available. Areas most impacted by the implementation of the database include: Frequency of costly disk or flash media I/O operations. Time required to recover from a crash or power loss. Page 2

3 Ability to manage large amounts of data without severe performance degradation. Performance impact of sharing data between tasks and other applications. Relative performance of read and write operations. Portability of the storage format and application code. Effort required to integrate database technology into the application. Database software must carefully balance the flow of data between persistent storage and memory. If information is not saved regularly, recovery from a power loss will be slower. If information is saved too often, performance will suffer and some media, such as flash memory, will wear out more quickly. Scalability is a concern for many applications, both for the amount of data stored and for the impact of sharing data. If scalability is not important, a database can greatly optimize performance. If scalability is needed, or may be needed in the future, the performance cost can be very high if the database has not provisioned for it. By considering the current and future requirements of an application, an embedded software developer can select the most appropriate database technology. 3. Standard SQL Benchmark ITTIA has conducted a benchmark to compare the performance of ITTIA DB SQL and SQLite, both with and without concurrent access to the database. The tests cover three fundamental SQL operations: insert, select, and update. This benchmark will measure elapsed time for three operations: Insert rows into an empty database. Select rows using indexed search. Update rows using indexed search. Each operation is divided evenly into one or more threads Test Environment The benchmark is performed for embedded developers on an ARM Linux device with the following characteristics: Operating System: Angstrom Linux Architecture: ARM9 Page 3

4 CPU Speed: 400Mhz RAM: 64 MiB Storage Media: SD Flash Card This device is typical of the low-power hardware that ITTIA DB SQL is typically deployed on Test Methodology This section describes the settings and algorithms used to conduct the benchmark test. Great care has been taken to achieve a fair comparison. However, the benchmarks have been optimized to make best possible use of the features available in each product, and any differences between the implementations have been noted here Product Configuration For this benchmark, the database products are configured as follows: ITTIA DB SQL Version Storage Type File File Connection Method Local Local Connections 1, 2, 4, 8 1, 2, 4, 8 Locking Mode Storage File API ITTIA DB C API SQLite C API Access Method SQL SQL SQLite Local access means that database files are opened directly from the benchmark process, without using any client/server connection. Files are stored on the test platform's storage media. For this test, storage-level locking and file-level locking are equivalent because exactly one database file is used at a time. However, a new database file is created each time a different number of connections tested. SQLite is configured, using the sqlite3_busy_handler() function, to yield the CPU whenever a lock is encountered and then continue waiting. ITTIA DB is configured by default to wait indefinitely on any lock. Page 4

5 Database Schema The following database schema is used for the benchmark: Listing 1: Schema create table benchmark_table ( a integer not null, b integer, unused1 integer, unused2 integer, unused3 integer, unused4 integer, unused5 integer, unused6 integer, unused7 integer, unused8 integer, unused9 integer, unused10 integer, unused11 integer, unused12 integer, unused13 integer, unused14 integer, unused15 integer, unused16 integer, unused17 integer, unused18 integer ); create unique index ix1 on benchmark_table (a); Parameters The following test parameters are used in the test algorithms: Parameter ITTIA DB SQL SQLite inserts 1,000 per thread 1,000 per thread selects 1,000 per thread 1,000 per thread updates 1,000 per thread 1,000 per thread transaction_size 1 row per transaction 40 rows per transaction sync_rate 40 transactions each transaction By default, both ITTIA DB SQL and SQLite will synchronize to the storage media at the end of each write transaction. In practice, it is rarely necessary to force synchronization for each individual insert or update. For that reason, this test has Page 5

6 been configured so that the database is synchronized for every 40 rows inserted or updated successfully. SQLite must synchronize the storage at the end of each transaction to guarantee that the database file can be recovered. Therefore, SQLite is configured to use 40 rows per transaction. Because ITTIA DB SQL does not have this limitation, it can achieve the same rate of synchronization with only one row per transaction, which improves concurrency Test Algorithms Each thread runs one of three algorithms: an insert, select, or update loop. A new connection to the database is opened for each thread. Insert threads all run concurrently, followed by all select threads, then all update threads. The algorithms used for each thread are defined below through pseudo code. In practice, the SQL queries used in each algorithm are prepared only once per thread. As a result, this benchmark is not significantly influenced by the overhead of SQL parsing and query planning. For the insert phase of the benchmark, each thread inserts rows starting at a different offset, so that the range of rows inserted by each thread do not overlap. Read committed isolation is used because no rows are ever read by the insert transactions. Listing 2: Benchmark Insert Algorithm insert_thread(int inserts, int transaction_size, int offset) { start transaction isolation level read committed; for(long i = 1 + offset; i <= inserts + offset; i++) { insert into benchmark_table(a, b) values(i, i+2); } if (i % transaction_size == 0) { commit transaction; start transaction isolation level read committed; } } commit transaction; The select phase of the benchmark randomly selects from the rows that were added in the insert phase, to test index search performance. Repeatable read isolation level is used to ensure that if the same row is selected more than once in the same Page 6

7 transaction, its value will not change. Listing 3: Benchmark Select Algorithm select_thread(int selects, int transaction_size, int total_rows) { begin transaction isolation level repeatable read; for (long i = 1; i <= selects; i++) { long value = (rand() % total_rows) + 1; select b from benchmark_table where a = value; } if (i % transaction_size == 0) { commit transaction; begin transaction isolation level repeatable read; } } commit transaction; In the update phase, each thread randomly chooses one row at a time to update. The updated column is not indexed. Repeatable read isolation level is used to ensure that two threads do not overwrite the same row simultaneously. Listing 4: Benchmark Update Algorithm update_thread(int updates, int transaction_size, int total_rows) { begin transaction isolation level repeatable read; for (long i = 1; i <= updates; i++) { long value = (rand() % total_rows) + 1; update benchmark_table set b = value + 8 where a = value; } if (i % max_updates_per_tx == 0) { commit transaction; begin transaction isolation level repeatable read; } } commit transaction; A few subtle details are not presented in the pseudo code for each algorithm: The durability_rate parameter defines the frequency with which committed transactions are flushed to the persistent storage media. When the Page 7

8 durability_rate is 1, all transactions are synchronized immediately. SQLite does not support isolation levels. Therefore all SQLite transactions are considered serializable. When a deadlock is detected, the transaction is rolled back and repeated. Rows accessed in the aborted transaction are not counted in the total, so that the cost of resolving deadlocks is accounted for in the benchmark results Results Results are measured as a ratio of elapsed time for SQLite to elapsed time for ITTIA DB. A result of 1.00 indicates equivalent performance. Values greater than 1.00 favor ITTIA DB. Values less than 1.00 favor SQLite insert select update Regardless of the number of transactions, ITTIA DB retains a constant advantage for insert and update operations, with competitive performance in select. 4. Key Features All embedded databases serve three main purposes for data management: Reliable storage Efficient queries Page 8

9 Safe shared access Balancing these three areas of functionality is difficult because strong guarantees in one area can weaken the capabilities of the other two areas. For example, ensuring that data is saved reliably has some performance cost and imposes limits on when data can be shared. An embedded database hides many of the details of these tradeoffs from the application developer, instead offering options that shift focus into the areas that matter most for the specific application. Without these options, it can be difficult or impossible to achieve the necessary performance, reliability, or availability of data Atomic Transactions An embedded database groups related database operations together into transactions. Changes to a database file are only saved when the transaction is completed successfully, so that incomplete work can be automatically rolled back when an error occurs, even if parts have already been written to storage media. From the application's perspective, each transaction is atomic. ITTIA DB SQL and SQLite both support atomic commit, but with different performance characteristics. SQLite creates a rollback journal for each transaction that remembers the original value before each change is made. ITTIA DB stores both the original value and the new value in a write-ahead log that can be shared by multiple transactions. This has some surprising results on overall performance. When a transaction is committed, the database must write enough information to disk to guarantee that no changes made in the transaction are lost. Data is organized into pages to optimize access to block devices such as disks and flash memory. In most cases, changes are scattered throughout the database, only modifying a small portion of each page. When SQLite commits a transaction, it must write all modified pages to disk in their entirety and then wait for the operation to finish. This is extremely costly, but necessary to support recovery with only a rollback journal. When ITTIA DB SQL commits a transaction, only the write-ahead log must be written immediately because it contains a copy of all the changes made in the transaction. Log entries are written sequentially and only contain information about changes, so fewer pages are written to disk. Other modified pages are written to disk later, after accumulating changes from many transactions. ITTIA DB SQL can also use lazy completion, which also delays the writing of log entries. In this mode, committed transactions are not saved immediately, but locks are released so that other connections can access the database. Page 9

10 Under high load, ITTIA DB SQL can significantly reduce the amount of write activity compared to SQLite, both boosting performance and reducing wear on flash storage media. With lazy completion enabled, many small concurrent transactions can be completed very efficiently Concurrency and Shared Access Device applications usually perform many different tasks on data stored in the database. Some tasks perform best when run in parallel, allowing long-running tasks such as synchronization to happen without completely stopping normal operations. Tasks can be performed by a single application with multiple threads or instances, multiple applications on a device, or even remote applications across a network. SQLite uses the locking mechanism built-in to the file system to protect database files during modification, which allows any process on the device with access to the file to use the database. This approach relies on the stability of the file system locking framework, and therefore cannot be used with files that are shared over a network. Many operating systems do not fully implement the range locks required to safely share an SQLite database. ITTIA DB SQL uses a lightweight data server to negotiate shared access. The server is self-contained, requiring little or no configuration so that it is straightforward to use on a device, and can even run in the background of an application process. Clients can connect to a server on the same device using an efficient shared memory protocol, or use TCP/IP networking. After opening a connection to the server, accessing data is no different from accessing a local database file. File system locks operate on an entire file at once, so when an SQLite transaction begins to modify the database, it must obtain exclusive access to the entire database file until the transaction is finished. This is not a problem when sharing is infrequent and every transaction only involves one or a few rows. However, one long-running transaction, such as a synchronization task, can block all other activity in the database, even when there is no real conflict. ITTIA DB SQL uses a less restrictive locking technique: row-level locking with isolation levels. The database automatically tracks all rows that are read or modified in a transaction. At the highest level of isolation, known as "serializable," rows are locked in such a way as to prevent all possible conflicts. And for most simple transactions, the isolation level can be reduced to minimize locking even further. This ensures that a transaction is only blocked when it would create a conflict with another transaction already in progress. In addition, an entire table can be locked manually. Page 10

11 All transactions in SQLite use serialization isolation. Row-level locking is also available when an ITTIA DB SQL database is shared between threads in an application. SQLite allows an open database to be shared between threads, but only one thread can modify the database at a time. ITTIA DB SQL permits multiple threads to concurrently read and modify different rows in the same database without risk of conflict Data Typing and Type Safety Embedded databases can store many types of information, the most common being numbers, text, date, and time. A value's data type must be known when it is read, whether it is used in an expression, displayed as text, or copied into a native variable. Many types are incompatible: a string of text cannot always be used where a number is expected, and large numbers will not fit in an 8-bit variable. To prevent a type mismatch, the database can check a value's data type either when it is written to the database, or when it is read. In the first case, the database must have some information about how the value will be used later so that it can check incoming values for conformance, and when a type mismatch occurs, the error must be reconciled when the value is stored in the database. In the case where the value is checked at read time, the database must be able to accommodate values of arbitrary type, and type mismatch errors are not handled until the value is read. SQLite uses dynamic run-time typing, which means that data types are only checked when a value is read from the database and used. This is useful in prototyping, before the application's requirements are fully formed, because it allows data to be written to the database without much regard for how it will be used later. Production code, however, must be carefully audited to ensure that type mismatches are not possible or can be dealt with in a reasonable way. ITTIA DB SQL uses static typing, where type information is stored in the database schema as part of a table's description. Each column can contain only a specific type of data. This ensures that type mismatch errors are identified early, when there is the best chance to successfully fix the mistake. This is important when the database is shared between applications that are developed separately, as the database schema forms a contract by which all parties must abide. Page 11

12 4.4. Application Programming Interface ITTIA DB SQL and SQLite each have an interactive utility that provides access to database files through standard SQL commands. While this is suitable for testing and maintenance, applications need a native interface to access the database. To access data in an SQLite database, applications use SQL queries. ITTIA DB SQL similarly supports SQL queries, but also provides direct access to tables and indexes with low-level table cursors. Table cursors have lower overhead than SQL queries and allow modifications to be made directly while browsing a table, without constructing an update query. In many cases, an application can use table cursors to both improve performance and minimize data layer source code. To protect a database from unauthorized access, the database file can be encrypted. ITTIA DB SQL provides encryption callbacks for an application to plug in any desired page-level encryption library. SQLite users must purchase the SQLite Encryption Extension (SEE), which utilizes password-based AES encryption only. Both products decrypt data when it is read from disk and encrypt data before it is written to disk. Developers of embedded systems and intelligent devices find it important to protect their database from unauthorized access. This significant requirement was recognized by the architects of ITTIA DB SQL. ITTIA DB SQL provides encryption callbacks that an application utilizes to plug in any desired page-level encryption library. This important feature is not included in the open source version of SQLite. 5. Practical Storage Logic Performance is critical in embedded applications. ITTIA recognizes the need for scalable performance across all operations, whether reading or writing to the database. Sometimes, disk access is too slow, even if it can be reduced to the minimum number of I/O operations. In other cases, disk access is unavoidable because the application needs random access to data that won't fit in main memory. For this reason, ITTIA DB SQL provides two different storage back-ends memory and file storage so that application developers can decide when to trade off memory footprint and persistence for performance. Hybrid databases, which use a mixture of memory and disk tables, allow applications to seamlessly integrate both storage models On-Disk File Storage Disk tables are stored in a database file, either on a hard disk, flash media, or other Page 12

13 block I/O device. Disk tables use B+ indexes to efficiently search the database. B+ tree indexes are optimized to minimize disk I/O, so that any row in any table can be located with just a few I/O operations. At the same time, ITTIA DB SQL automatically manages a page cache in RAM to avoid disk I/O whenever possible. Clustering ensures that, in practice, most requests can be serviced by the cache. This design ensures that large tables can be accessed efficiently, even with a limited amount of RAM In-Memory Storage Some devices have sufficient memory to store data entirely in main memory. To optimize for this scenario, ITTIA DB SQL also supports in-memory storage. When a database is created in memory, ITTIA DB SQL uses algorithms that are specialized for memory tables, such as T-tree indexes. In this way, ITTIA DB SQL is able to take advantage of optimizations such as direct pointers to significantly improve performance. Like disk tables, memory tables are shared between connections to the ITTIA DB SQL database. Transactions are used to protect incomplete changes from being accessed by other connections. While SQLite supports memory databases, they store data in the same format that is used for disk tables. SQLite memory databases are private to each connection, and cannot be shared between different tasks. 6. High Availability When a mission critical data becomes unavailable, then the entire system can be threatened. Support for high availability (HA) in ITTIA DB SQL maximizes the protection and availability of data. Backup, replication and recoverability are three characteristics of a highly available solution. ITTIA DB SQL is a database that guarantees the access and availability of the data for the application. When a system failure occurs, there are several ways to recover from it. It is important to determine and predict how a failure may happen and how to recover in the time that meets your system architecture requirements. For example, if a critical table or row is accidentally deleted from the database, what action should be taken? Does database provide the ability to recover in timely manner? A highly available database architecture has the following characteristics: Failures are handled transparently Page 13

14 Provide fast recoverability Automate recovery Protect the data from loss ITTIA DB SQL offers high availability solutions so that mission-critical data is reliably accessible. The only high availability offered by SQLite is a limited backup solution. 7. Replication ITTIA DB SQL supports database replication. Replication is used to share information between redundant resources to improve reliability, fault-tolerance, or accessibility. The replication facilities in ITTIA DB SQL make it easy to keep devices up-to-date with each other, even when connectivity is intermittent. When replication is enabled, changes to the database row insert, update, or delete are stored in the log file as replication events. Each database file has a list of peer databases with which it can exchange replication events. When an exchange occurs between two databases, both log files are scanned for replication events. Conflicts can occur if the same row has been modified in both databases, but there are methods to detect and handle conflicts. Peer databases can all reside on the same device, or connect over a network. If a network connection is not always available, replication events are accumulated in the log until an exchange is possible. The log-based replication approach used by ITTIA DB has several advantages over alternative methods: Transaction boundaries are preserved in the replication log. If a replication event cannot be applied to a recipient database because it violates a constraint, no other events are applied from the same transaction. This prevents inconsistency in the recipient database. The order of changes is preserved. Replication events are applied to the recipient database in the same order that they occurred in the source database. Performance is consistent, regardless of the number of peer databases. The same replication log is shared between all peers. 8. Device Notification An advanced feature of ITTIA DB SQL, data change notification, allows an application to receive an automatic notification whenever another application makes Page 14

15 a change in the database. This is a convenient way to send messages between applications that are sharing the database. To receive change notifications, an application opens a connection to the database, subscribes to one or more tables, and periodically polls the connection for change events. When a row is inserted or updated by another connection, a change event is sent at the end of the transaction. A bookmark to the modified row is included in the change event, so that the recipient can view the row, or even modify it. SQLite applications can register callback functions to be notified when a row is changed. However, this feature only monitors changes made by the current connection, and cannot be used to monitor other connections to the database. Furthermore, the callback functions are invoked immediately, while executing the change, and must not access the database during the callback. 9. Technical Support Technical support for embedded database is much more involved than in other fields of software. Database technology is complex, and requires deep technical insight to use effectively. There will be times that you need in-depth familiarity and support for a feature in the database and cannot wait for public opinion to form a consensus. If you need an answer immediately, it may cost more than you expected. SQLite is supported through forums and mailing lists. Large corporations can join the SQLite Consortium, but SQLite customer support is a big question mark for everyone else. There is no reliable phone or support, and forum members are not responsible for answering your questions. Do you want answers to your questions in a timely manner? Furthermore, the SQLite community does not have a business obligation to answer any support questions and, in most cases, one has to figure it out or hire the services of a consultant. Will the upgrades, updates, and patches be available into the foreseeable future? Will your customizations be compatible with future releases of SQLite? If you need upgrades and fixes not supported by SQLite, you'll have to help yourself. Unless you sign up for an expensive support package, consultancy or consortium membership, the available technical supports are online forums and search engines. You will need a real company to be accountable for your database needs. The future may be quite uncertain, as developers working on SQLite may lose interest at any time and leave the project! ITTIA establishes a working relationship with its Page 15

16 customers during their application development, so that they can be successful with ITTIA DB SQL. When you select ITTIA DB SQL, you will benefit from a dependable, world-class support. Whether you are a small company or a Fortune 500 organization, your success with ITTIA DB SQL is our number one priority. Continuous access to software patches, enhancements, upgrades, and experienced risk management advice are all part of the value offered by the ITTIA technical support team. 10. Conclusion SQLite seems like a free SDK for embedding application with a database, but developers should be aware of its risks. SQLite is not only expensive to replace. As many companies have found out, SQLite can also be quite pricey and risky to maintain over the long run. When a developer embeds their application with SQLite, they decide to become a database company and manage their own updates, upgrades and patches. As many companies have learned, SQLite can be very complex to manage. You have to download the latest "stable" release and embed it. You have to keep up with product updates (and if the person who is running SQLite one day lose interest in this hobby and stop updating the SQLite site, then what will happened to you? You are ultimately responsible for the maintenance of the database. Are you ready to become a database company or do you prefer to focus on your business logic and gain competitive edge by focusing on your field of expertise? Looking beyond current functionality, knowing the future directions of the database library you select provides an important level of assurance. ITTIA is very open with its customers in sharing the development road map for ITTIA DB SQL. The To Do list for SQLite is currently about three years old. In the beginning, it may appear as though you are saving money with SQLite, but in the long run you may find yourself locked in to a technology that is more costly than expected. The risk associated with a delay in project completion is far to great when compared to the investment in database licensing. There are many technical reasons to choose ITTIA DB: 1. Performance: Whether database access is limited to one connection at a time, or divided between several concurrent tasks, ITTIA DB SQL shows a significant performance advantage for database writes. 2. Low-level access to the engine: Each embedded application has unique Page 16

17 requirements for data management and storage. Selecting the right tools requires a careful problem analysis and a thorough understanding of database technology. Using a technology with the right features makes a significant impact on the performance, maintainability, and extensibility of the application. 3. Concurrency: SQLite is designed and developed for isolated systems that are single users/thread. Application that initially starts, as a single user will run tremendous difficulties when they need to support concurrency. Often used as a stand-alone database software library, ITTIA DB SQL greatly simplifies data management for applications on embedded systems and devices, but without the complexity of a back-end database server. SQLite is suited for simple projects that need basic transactional storage using SQL. SQLite takes advantage of self-imposed limitations to optimize for the most basic use cases. Advanced projects with robust or undefined requirements can benefit from ITTIA DB SQL's solid framework for formalizing, updating, and sharing data. Benchmarks show that even for simple operations, ITTIA DB outperforms SQLite. 4. Replication: ITTIA DB SQL supports built-in replication that duplicates changes across multiple databases, even if connectivity is not always available. SQLite provides no replication functionality. 5. ANSI Standards: From the earliest stages of ITTIA DB SQL s design and development, engineering team at ITTIA followed the ANSI SQL standards. Unlike SQLite, which attempts to compromise between the non-standard SQL functionality from other database vendors, ITTIA DB SQL has and will follow the standards. 6. Data typing and type safety: The static typing in ITTIA DB SQL offers greater protection than the manifest typing in SQLite. 7. True in-memory storage engine: For memory storage, SQLite uses the same algorithms that are optimized to minimize disk I/O. ITTIA DB uses algorithms that are optimized for both read and write performance in RAM. 8. High availability: The combination of built-in replication, client/server communications, online backup, and high-performance recovery in ITTIA DB SQL gives developers a complete set of tools to achieve fault tolerance through both self-stabilization and duplication. SQLite only provides basic recovery logging and limited online backup, important tools for selfstabilization but hardly a complete solution. Page 17

18 About ITTIA ITTIA provides software and services for data management, offering standards, ease of use, and flexibility to our customers. Benefits of selecting ITTIA s technologies include leading-edge software, comprehensive documentation, scalability, efficiency, exceptional performance, and low total cost of ownership. Learn how customers such as Freescale Semiconductor, Panasonic, Puget Sound Energy, Fresenius, Boeing, and others have valued from ITTIA by visiting: Page 18

19 How to Reach Us Home Page: Contact: USA: ITTIA th Ave Bellevue, WA Information in this document is provided solely to enable system and software implementers to use ITTIA products. No express or implied copyright license is granted hereunder to design or implement any database management system software based on the information in this document. ITTIA reserves the right to make changes without further notice to any products described herein. ITTIA makes no warranty, representation or guarantee regarding the suitability of its products for any particular purpose, nor does ITTIA assume any liability arising out of the application of or use of any product, and specifically disclaims any and all liability, including without limitation consequential or incidental damages. Statistics and parameters provided in ITTIA white papers and data sheets can and do vary in different applications and actual performance may vary over time. All operating parameters must be validated for each customer application by customer's technical experts. ITTIA and the ITTIA logo are trademarks or registered trademarks of ITTIA, L.L.C. in the U.S. and other countries. All other product or service names are the property of their respective owners. Copyright 2011, ITTIA L.L.C. All rights Reserved. Rev 1 Page 19